py3k s***s
Sverker Nilsson
come on you braver men
we are at least not bought by g***le
but why? others have said it so many times i think
:-////
but why? a few syntactic 'cleanups' for the cost of a huge rewrite of
all the code that have been builtup from all the beginning when the
once great Python came along and people began to use it and write code
for it. Like all that code would have to be rewritten. blaah.
and i have perhaps been drinking but i have been p**d all week since i
began look into this:-(
Steve Holden
Perhaps you should sober up and look at the reality of Python 3, which
has deliberately avoided a complete rewrite.
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
Ben Finney
> do i dare to open a thread about this?
If you do so, please use less inflammatory language. You can't expect
a reasoned debate if you use such hyperbole and emotional attacks.
Discussion is welcome. Flaming isn't.
--
\ "He who laughs last, thinks slowest." -- Anonymous |
`\ |
_o__) |
Ben Finney
ajaksu
> come on you braver men
Yeah!
> we are at least not bought by g***le
Hell no!
> but why? others have said it so many times i think
Huh?!
> :-////
?! Whatever!
> but why? a few syntactic 'cleanups' for the cost of a huge rewrite of
> all the code that have been builtup from all the beginning when the
> once great Python came along and people began to use it and write code
> for it. Like all that code would have to be rewritten. blaah.
Yeah! Woo-hoo!
Wait... What? No, no, you got it all wrong. Python developers are
being extra-careful and doing a lot of hard work to keep things sane,
allow easy migration, etc.
> and i have perhaps been drinking but i have been p**d all week since i
> began look into this:-(
Ah, OK, calm down and look again. Things are way better than you
think, but there is a lot of FUD going on too, so focus on serious,
reliable reports.
Cheers,
Daniel
Sverker Nilsson
> Sverker Nilsson wrote:
> > do i dare to open a thread about this?
>
> > come on you braver men
>
> > we are at least not bought by g***le
>
> > but why? others have said it so many times i think
>
> > :-////
>
> > but why? a few syntactic 'cleanups' for the cost of a huge rewrite of
I tried out py3k on my project, http://guppy-pe.sf.net
And i have looked into py3k also at the list and read quite a bit
about it.
no fun, to me at least
Try it yourself, all contributions are welcome of course
Sverker
Sverker Nilsson
I was serious! It's just from my right brain half. I take it you are
ironic, I appreciate it, hope we will hear from some Director.....
doesnt matter perhapss
I said what I said, now I am just trollin or trying
How do one troll best?
I know but I can also sell you Rolexes for a good price...
S--
And what should I say? Perhaps that the debate on the the py3k list is
---- I cant find the word because i am swedish, but it is just that
most people or some are so concerned about they having 'commit-
privileges' that the don't dare say anything contoversial that would
go against mr. GVR. so this is a much freer forum.Not that I am more
intelligent than GVR but we can at least debate, though I doubt he has
the time:-)
So, regrds to all and hope you guys want to continut the debate...
Sverker
Gabriel Genellina
> I tried out py3k on my project, http://guppy-pe.sf.net
And what happened?
I've seen that your project already supports Python 2.6 so the migration
path to 3.0 should be easy.
--
Gabriel Genellina
Sverker Nilsson
Sverker Nilsson
wrote:> > I tried out py3k on my project,http://guppy-pe.sf.net
>
> And what happened?
> I've seen that your project already supports Python 2.6 so the migration
> path to 3.0 should be easy.
>
> --
> Gabriel Genellina
2.6 was no big deal, It was an annoyance that they had to make 'as' a
reserved word. Annoyances were also with 2.4, and 2.5. No big
problems, I could make guppy backwards compatible to 2.3. But that
seems not to be possible with Python 3.x ... it is a MUCH bigger
change. And it would require a fork of the code bases, in C, Guido has
written tha or to sprinkle with #ifdefs. Would not happen soon for me.
It takes some work anyways. Do you volunteer, Guido van Rossum? :-)
It's not exactly easy. Perhaps not very hard anyways. But think of
1000's of such projects. How many do you think there are? I think
many. How many do yo think care? I think few.
When it has been the fuzz with versions before, then I could have the
same code still work with older versions. But now it seems I have to
fork TWO codes. It's becoming too much. Think of the time you could
write a program in C or even C++ and then it'll work. How do you think
eg writers of bash or other unix utilities come along. Do they have to
rewrite their code each year? No, it stays. And they can be happy
about that, and go on to other things. Why should I have to think
about staying compatible with the newest fancy Python all the time? NO
-- but the answer may be, they don't care, though the others (C/C++,
as they rely on) do. :-(
Sverker
Gabriel Genellina
> On Apr 15, 3:50 am, "Gabriel Genellina" <gagsl-...@yahoo.com.ar>
> wrote:
>> En Mon, 14 Apr 2008 22:02:38 -0300, Sverker Nilsson <s...@sncs.se>
>> escribió:
>>
>> > I tried out py3k on my project,http://guppy-pe.sf.net
>>
>> And what happened?
>> I've seen that your project already supports Python 2.6 so the migration
>> path to 3.0 should be easy.
>
> reserved word. Annoyances were also with 2.4, and 2.5. No big
> problems, I could make guppy backwards compatible to 2.3. But that
> seems not to be possible with Python 3.x ... it is a MUCH bigger
> change. And it would require a fork of the code bases, in C, Guido has
> written tha or to sprinkle with #ifdefs. Would not happen soon for me.
> It takes some work anyways. Do you volunteer, Guido van Rossum? :-)
>
> It's not exactly easy. Perhaps not very hard anyways. But think of
> 1000's of such projects. How many do you think there are? I think
> many. How many do yo think care? I think few.
>
> When it has been the fuzz with versions before, then I could have the
> same code still work with older versions. But now it seems I have to
> fork TWO codes. It's becoming too much. Think of the time you could
> write a program in C or even C++ and then it'll work. How do you think
> eg writers of bash or other unix utilities come along. Do they have to
> rewrite their code each year? No, it stays. And they can be happy
> about that, and go on to other things. Why should I have to think
> about staying compatible with the newest fancy Python all the time? NO
> -- but the answer may be, they don't care, though the others (C/C++,
> as they rely on) do. :-(
You can stay with Python 2.6 and not support 3.0; nobody will force you to
use it. And nobody will come and wipe out your Python installation, be it
2.6, 2.1 or whatever. And if you still enjoy using Python 1.5, please keep
using it - it won't disappear the day after 3.0 becomes available.
Regarding the C language: yes, souce code *had* to be modified for newer
versions of the language and/or compiler. See by example, the new
"restrict" keyword in C99, or the boolean names. The C guys are much more
concerned about backwards compatibility than Python, but they can't
guarantee that (at risk of freezing the language). The 3.0
incompatibilities are all justified, anyway, and Python is changing (as a
language) much more than C - and that's a good thing.
There is a strategy to migrate from 2.x to 3.0, including the 2to3 tool.
Have you used it?
--
Gabriel Genellina
Sverker Nilsson
then a 3.1 whatever.
I don't want that fuzz. As about the C versions, I am not that
worried. What's your point?
I just like want to write a program that will stay working. And maybe
I can go on with something else hopefully than just compatibility
fixes. They take some work afterall.
It seems hard with Python. Esp. 2 -> 3
Sverker
On Apr 15, 5:41 am, "Gabriel Genellina" <gagsl-...@yahoo.com.ar>
Gabriel Genellina
> No one forces me, but sooner or later they will want a Python 3.0 and
> then a 3.1 whatever.
Welcome to the software industry!
If it isn't Python changing, it's the operating system, the processor
architecture, the network connectivity, whatever. Only very abstract and
generic applications may survive a long time without being affected by
changes in the environment. You choose to develop a very specific tool
tied to the specifics of memory management in Python (a really good idea,
btw), but unfortunately you'll have to adapt it to changes in the language.
> I don't want that fuzz. As about the C versions, I am not that
> worried. What's your point?
You said that a C program doesn't have to be changed when the
compiler/language changes, and I refuted that assertion.
> I just like want to write a program that will stay working. And maybe
> I can go on with something else hopefully than just compatibility
> fixes. They take some work afterall.
>
> It seems hard with Python. Esp. 2 -> 3
Bad luck, you just decided to write your program in the transition
phase... In a couple years, I think 3 will be reasonably as stable as 2.x
today.
--
Gabriel Genellina
ajaksu
> What serious reports?
You almost had me collecting a list of reports/references. Almost :)
Google and you'll find them.
Regards,
Daniel
Gerhard Häring
> [about code supporting multiple Python versions]
> When it has been the fuzz with versions before, then I could have the
> same code still work with older versions. But now it seems I have to
I don't think many people have ported their C extensions to Python 3.0,
yet. I've had the dubious privilege for pysqlite/the sqlite 3 module.
And I find that's a bigger pain than the Python level. Way too many
#ifdefs. I don't like branching projects, but this seems to be the only
sensible approach here.
-- Gerhard
Chris McAloney
On 15-Apr-08, at 12:30 AM, Sverker Nilsson wrote:
> No one forces me, but sooner or later they will want a Python 3.0 and
> then a 3.1 whatever.
>
> I don't want that fuzz. As about the C versions, I am not that
> worried. What's your point?
>
> I just like want to write a program that will stay working. And maybe
> I can go on with something else hopefully than just compatibility
> fixes. They take some work afterall.
>
> It seems hard with Python. Esp. 2 -> 3
I couldn't help but notice that not only did you not address
Gabriel's most important question, you excluded it from the quote
below and changed the comma to a period. Gabriel said:
"There is a strategy to migrate from 2.x to 3.0, including the 2to3
tool.
Have you used it?"
*Have* you tried the 2to3 tool? It might help to lessen your
concerns a bit. Yes, Python 3 is different from 2.x, but we've known
that it was going to be for years and, as has already been pointed
out, the devs are being very careful to minimize the pain that the
changes will inflict on Python programmers, with tools such as 2to3.
Chris
Michael Torrie
> *Have* you tried the 2to3 tool? It might help to lessen your
> concerns a bit. Yes, Python 3 is different from 2.x, but we've known
> that it was going to be for years and, as has already been pointed
> out, the devs are being very careful to minimize the pain that the
> changes will inflict on Python programmers, with tools such as 2to3.
After parsing this thread through a noise filter, it appears the main
concern is not the converting of _python code_ from 2 to 3, but rather
converting extensions written in C, or when python is embedded in a C
program. The APIs have necessarily changed, and this *will* inflict a
certain amount of pain and suffering on the developer, especially if he
needs to maintain code for both python 2 and python 3. However this is
just the way it is. It's a bit like complaining that I have to rewrite
my app with win32 calls and paradigms when I was used to win16. No
conversion will be completely pain free, but this jump is pretty
insignificant compared to others in the industry.
I think the original poster is being somewhat unreasonable, though. No
one is going to force him to 3. If his end users demand it, and he's
selling them software, then he'll do it or else go out of business. If
it's OSS, he'll either do it, or someone else will fork it and take it
forward.
Donn Cave
<11567a1a-b184-42e6...@p25g2000hsf.googlegroups.com>,
Sverker Nilsson <s...@sncs.se> wrote:
> No one forces me, but sooner or later they will want a Python 3.0 and
> then a 3.1 whatever.
>
> I don't want that fuzz. As about the C versions, I am not that
> worried. What's your point?
>
> I just like want to write a program that will stay working. And maybe
> I can go on with something else hopefully than just compatibility
> fixes. They take some work afterall.
>
> It seems hard with Python. Esp. 2 -> 3
Welcome to the world of Python.
There was a period of relative stability in the '90s, culminating
with version 1.5.2, which just happens to be about the time that
people started taking Python seriously. It turns out that this
stability was only due to lack of resources, though.
I think most of us are working under two imperatives here that
really boil down to the same thing: we want a programming
language that lets us focus on the goal of the program. On
one hand, that means things like automatic memory management
that are brought to us by newer languages (i.e., less than
30 years old.) On the other hand it means stability that allows
our deployed code to go on working without constant intervention,
which usually we find in languages that have become utterly boring
and out of fashion (i.e., more than 30 years old.)
It's hard to find a good compromise between these two, in an
interpreted language. I don't know what the current party line
may be on this matter, but some years back it was that you should
consider the interpreter part of your application. That is, each
application should deploy with its own dedicated Python interpreter,
complete with libraries and everything. This naturally relieves
some of the maintenance issues, since at least you can upgrade on
your own schedule, but of course it has its costs too. Anyone who
might be thinking about using Python for an application should
seriously think about this.
Donn Cave, do...@u.washington.edu
Terry Reedy
"Sverker Nilsson" <s...@sncs.se> wrote in message
news:eda75e1a-904e-4916...@m44g2000hsc.googlegroups.com...
| What serious reports?
Sverker Nilsson
Providing the Python infrastructure with my program doesn't apply
since I am providing a program/library that is intended to be
general.
So it doesn't help.
All that py3k does to me, it seems, is some extra work.
To be frank, no innovation. Just changes, no progress. And yes, I am
p****d.
Somebody compared it with MS stuff. Yes.
Nothing personal, I appreciate Your comment. And all others.
Sverker
On Apr 15, 7:09 pm, Donn Cave <d...@u.washington.edu> wrote:
> In article
> <11567a1a-b184-42e6-bbf3-a655736c1...@p25g2000hsf.googlegroups.com>,
> Donn Cave, d...@u.washington.edu
Damjan
> p****d.
"anger leads to hate, hate leads to suffering"
> Somebody compared it with MS stuff. Yes.
It's not similar at all. MS will first force all your customers/users to
upgrade to their newest software, at the same time suffocating the old
software, and denying anyone the oportunity to maintain that old software
(part because it's closed-source, part because MS will sue you if try
anything close to that).
--
damjan
Aaron Watters
> No one forces me, but sooner or later they will want a Python 3.0 and
> then a 3.1 whatever.
>
> I don't want that fuzz. As about the C versions, I am not that
> worried. What's your point?
>
> I just like want to write a program that will stay working.
Maybe I'll see the wisdom of py 3k eventually, if I don't die first,
but I have to agree with Sverker's general comments. Just yesterday
I had a conversation with someone who thinks maybe Ruby is better
than Python -- the one really good argument Python
has against nearly all contenders is all the
stuff out there you can get so easily -- all the stuff that py3k
will break -- most of which won't get ported -- and if it does can
we be sure it will be tested properly? No, probably you will end
up beta testing someone's quick port of what used to be rock
solid code... This was quite rightly pointed out to me, and
I had to agree that it was a pretty good point.
In my opinion python's adherence to backwards compatibility
has been a bit mythological anyway -- many new python versions
have broken my old code for no good reason. This is an irritant
when you have thousands of users out there who suddenly drop
your code, blame you and python, and move on to use something else.
Honestly, how hard would it have been to provide standard backwards
support for the old regex module as a standard module which simply
translated one regex string format to another, for example?
I don't get it. It ain't broke. Don't fix it.
At long last Python has a full head of steam and py3k
is just confusing everyone.
But I've been wrong before (twice). I also once thought generators
were a mistake :) (but I still think full stackless would be
much better, which python seems to be very slowly moving
towards.....)
-- Aaron Watters
===
http://www.xfeedme.com/nucular/pydistro.py/go?FREETEXT=nonsense
Marco Mariani
> stuff out there you can get so easily -- all the stuff that py3k
> will break -- most of which won't get ported -- and if it does can
> we be sure it will be tested properly? No, probably you will end
> up beta testing someone's quick port of what used to be rock
> solid code... This was quite rightly pointed out to me, and
> I had to agree that it was a pretty good point.
Do you mean Ruby's track in providing backward compatibility is better
than Python's?
Googling for that a bit, I would reckon otherwise.
Aaron Watters
>
> Do you mean Ruby's track in providing backward compatibility is better
> than Python's?
>
> Googling for that a bit, I would reckon otherwise.
I can't comment on that. Ruby is a lot younger
-- I'd expect it to still be stabilizing a bit.
What I'm saying is that, for example, there are a lot
of cool tools out there for using Python to manipulate
postscript and latex and such. Most of those tools
require no maintenance, and the authors are not paying
any attention to them, and they aren't interested in
messing with them anymore.
My guess is that there are few
such tools for Ruby. However, I wouldn't be too
surprised if porting them to Ruby and testing them
properly is not much more difficult than porting them
to py3k and testing them properly... Especially
since the basic treatment of strings is totally
different in py3k, it seems.
Maybe there is a secret desire in the Python
community to remain a fringe minority underdog
forever?
-- Aaron Watters
===
http://www.xfeedme.com/nucular/pydistro.py/go?FREETEXT=reap+dead+child
Gabriel Genellina
> In my opinion python's adherence to backwards compatibility
> has been a bit mythological anyway -- many new python versions
> have broken my old code for no good reason. This is an irritant
> when you have thousands of users out there who suddenly drop
> your code, blame you and python, and move on to use something else.
> Honestly, how hard would it have been to provide standard backwards
> support for the old regex module as a standard module which simply
> translated one regex string format to another, for example?
Do you mean this?
py> import reconvert
py> help(reconvert)
Help on module reconvert:
NAME
reconvert - Convert old ("regex") regular expressions to new
syntax ("re").
FILE
c:\apps\python24\lib\reconvert.py
DESCRIPTION
When imported as a module, there are two functions, with their own
strings:
convert(s, syntax=None) -- convert a regex regular expression to
re syntax
quote(s) -- return a quoted string literal
When used as a script, read a Python string literal (or any other
expression evaluating to a string) from stdin, and write the
translated expression to stdout as a string literal. Unless
stdout is
a tty, no trailing \n is written to stdout. This is done so that
it
can be used with Emacs C-U M-| (shell-command-on-region with
argument
which filters the region through the shell command).
> What I'm saying is that, for example, there are a lot
> of cool tools out there for using Python to manipulate
> postscript and latex and such. Most of those tools
> require no maintenance, and the authors are not paying
> any attention to them, and they aren't interested in
> messing with them anymore.
And they will continue to work using the Python version for which they
were designed, or even a later one; probably up to the last 2.x. Some
scripts designed for Python 1.x still work.
Really I don't feel the 3.0 incompatibilities are so big.
> My guess is that there are few
> such tools for Ruby. However, I wouldn't be too
> surprised if porting them to Ruby and testing them
> properly is not much more difficult than porting them
> to py3k and testing them properly...
If you have to convert the code to 3.x, 2to3 does most of the dirty
work. Of course you have to test properly - the same as with any new
version. And you can't say seriously than porting to Ruby is easier
than fixing the incompatibilities with 3.0
> Especially
> since the basic treatment of strings is totally
> different in py3k, it seems.
No. The new str type is the (renamed) old unicode type. Old strings
are called bytes now. Both are immutable and mostly support the same
old methods. Comparing (2.5) dir(u"") with (3.0) dir(""): decode() is
not supported anymore; new: isidentifier(), maketrans(). Comparing
(old) str with (new) bytes: encode() is not supported, nor format();
fromhex() added. So they look basically the same to me.
Ok, when in 2.x you write u"abc", it's spelled "abc" in 3.0; and when
you write "abc" it will be spelled b"abc". But that change is easily
done with the 2to3 tool, or using "from __future__ import
unicode_literals" in Python 2.6. Again, not so terrible.
It seems to me that the fear of the upcoming 3.0 is caused mostly by
lack of information.
--
Gabriel Genellina
Gabriel Genellina
>
> After parsing this thread through a noise filter, it appears the main
> concern is not the converting of _python code_ from 2 to 3, but rather
> converting extensions written in C, or when python is embedded in a C
> program. The APIs have necessarily changed, and this *will* inflict a
> certain amount of pain and suffering on the developer, especially if he
> needs to maintain code for both python 2 and python 3. However this is
> just the way it is. It's a bit like complaining that I have to rewrite
> my app with win32 calls and paradigms when I was used to win16. No
> conversion will be completely pain free, but this jump is pretty
> insignificant compared to others in the industry.
Yes, at the C level you have to either live with a lot of #ifdefs, or
maintain two branches. I prefer the second choice (with the help of a
good SCM tool) but that's a matter of taste or convenience.
--
Gabriel Genellina
Aaron Watters
> On 16 abr, 09:56, Aaron Watters <aaron.watt...@gmail.com> wrote:
>
> > In my opinion python's adherence to backwards compatibility
> > has been a bit mythological anyway -- many new python versions
> > have broken my old code for no good reason. This is an irritant
> > when you have thousands of users out there who suddenly drop
> > your code, blame you and python, and move on to use something else.
> > Honestly, how hard would it have been to provide standard backwards
> > support for the old regex module as a standard module which simply
> > translated one regex string format to another, for example?
>
> Do you mean this?
>
> py> import reconvert
Yes I mean it. Actually I was unaware
of/forgot reconvert, but it doesn't
matter because it doesn't solve the problem of code I wrote that
has long ago escaped into the wild no longer working. There are
other examples too, having to do with things as simple as a name
change in a standard module that broke old
code of mine for what I regard as silly cosmetic reasons.
I hope you are right about py3k conversions being pain
free and routine. I'm suspicious about it however.
-- Aaron Watters
===
http://www.xfeedme.com/nucular/pydistro.py/go?FREETEXT=cause+pain
Donn Cave
<cf36d4f6-11be-4788...@l42g2000hsc.googlegroups.com>,
Aaron Watters <aaron....@gmail.com> wrote:
> Maybe there is a secret desire in the Python
> community to remain a fringe minority underdog
> forever?
I'm sure anyone who has given it any thought understands that
the fringe minority situation is a lot more fun in some ways,
but I think if you were to apply a sort of conspiracy analysis
to the situation - "who benefits from language change" - this
would be a couple items down on the list of motivations.
Donn Cave, do...@u.washington.edu
Rhamphoryncus
> I don't get it. It ain't broke. Don't fix it.
So how would you have done the old-style class to new-style class
transition?
Aaron Watters
I'd ignore it. I never understood it and never had
any need for it anyway. New-style classes and metaclasses
were a complicated solution to an unimportant problem in
my opinion. And also a fiendish way to make code
inscrutible -- which I thought was more of a Perl thing
than a Python thing, or should be.
I must be missing some of the deeper issues here. Please
educate me.
-- Aaron Watters
===
http://www.xfeedme.com/nucular/pydistro.py/go?FREETEXT=killer%20joke
Chris Mellon
> On Apr 16, 12:27 pm, Rhamphoryncus <rha...@gmail.com> wrote:
> > On Apr 16, 6:56 am, Aaron Watters <aaron.watt...@gmail.com> wrote:
> >
> > > I don't get it. It ain't broke. Don't fix it.
> >
> > So how would you have done the old-style class to new-style class
> > transition?
>
> I'd ignore it. I never understood it and never had
> any need for it anyway. New-style classes and metaclasses
> were a complicated solution to an unimportant problem in
> my opinion. And also a fiendish way to make code
> inscrutible -- which I thought was more of a Perl thing
> than a Python thing, or should be.
>
> I must be missing some of the deeper issues here. Please
> educate me.
Since you don't care about any of the changes or features, and you
don't care if your users care, I'm not sure why you aren't just using
python 2.1. It's not like it's being erased via time machine. "Just
keep using the old thing" is a perfectly valid and extremely common
futureproofing scenario.
Aaron Watters
> Since you don't care about any of the changes or features, and you
> don't care if your users care, I'm not sure why you aren't just using
> python 2.1. It's not like it's being erased via time machine. "Just
> keep using the old thing" is a perfectly valid and extremely common
> futureproofing scenario.
Well for one thing newer versions of python are faster
and they come installed on other peoples linux and mac
boxes. If I were only interested in the box sitting in front
of me it sure would be a lot simpler. In reality even in
a simple environment I have to support 2.3 running on a 32
bit platform and 2.4 running on a 64 bit platform with the
same code. This is more of a pain than it should be.
Don't get me wrong. I like things like generators that actually
are useful (and amazingly fast also, I must say). I'd also
love to be able to use stackless which would be even cooler
but I can't because no-one else uses it to a first order approximation
and I don't want to be responsible for installing it all over
the place...
I'm interested in developing software for/getting software from
the python environment, ecosystem and community. In the short
term I foresee everything bifurcating into two separate code bases,
and I
think that's a shame, and I don't really see the need.
-- Aaron Watters
===
http://www.xfeedme.com/nucular/pydistro.py/go?FREETEXT=nightmare
Rhamphoryncus
> On Apr 16, 12:27 pm, Rhamphoryncus <rha...@gmail.com> wrote:
>
> > On Apr 16, 6:56 am, Aaron Watters <aaron.watt...@gmail.com> wrote:
>
> > > I don't get it. It ain't broke. Don't fix it.
>
> > So how would you have done the old-style class to new-style class
> > transition?
>
> I'd ignore it. I never understood it and never had
> any need for it anyway. New-style classes and metaclasses
> were a complicated solution to an unimportant problem in
> my opinion. And also a fiendish way to make code
> inscrutible -- which I thought was more of a Perl thing
> than a Python thing, or should be.
>
> I must be missing some of the deeper issues here. Please
> educate me.
>>> type(3)
<type 'int'>
>>> (3).__class__
Traceback (most recent call last):
File "<stdin>", line 1, in ?
AttributeError: 'int' object has no attribute '__class__'
>>> class Foo: pass
...
>>> type(Foo())
<type 'instance'>
>>> Foo().__class__
<class __main__.Foo at 0x811f47c>
With new-style classes, (3).__class__ returns int and type(Foo())
returns Foo.
Of course a lot of other aspects were redesigned at the same time,
such as how attributes/methods are looked up. The consequence of that
is we got descriptors. Seems like a fair trade to me.
Another example of an incompatible change was this:
>>> 2**32
Traceback (most recent call last):
File "<stdin>", line 1, in ?
OverflowError: integer exponentiation
In recent versions of 2.x you get this instead:
>>> 2**32
4294967296L
Finally, 3.0 changes it to this:
>>> 2**32
4294967296
Personally, I find all these changes to be a good thing. They make
the language cleaner and more useful. The only reason to not make the
changes is that old, crufty, unmaintained libraries & applications
might depend on them somehow. If that's more important to you, what
you really want is a language who's specs are frozen - much like C
effectively is. I hope python doesn't become that for a long time
yet, as there's too much it could do better.
Aaron Watters
> The only reason to not make the
> changes is that old, crufty, unmaintained libraries & applications
> might depend on them somehow. If that's more important to you, what
> you really want is a language who's specs are frozen - much like C
> effectively is. I hope python doesn't become that for a long time
> yet, as there's too much it could do better.
I'm feeling a bit old, crufty, and unmaintained myself,
but I'll try not to take offense.
There is a difference between something that works fine
until the rug gets pulled out and something that needs fixing.
It's a shame to junk stuff that works.
Also in the case of C/java etc changing the infrastructure
is less scary because you usually find out about problems
when the compile or link fails. For Python you may not find
out about it until the program has been run many times.
Perhaps this will inspire improved linters and better coding
practices....
I suppose if the py3k migration inspires tons of
insomniac young programmers to seek fame and admiration
by cleaning up ancient libraries, it would be a good
thing. It seems to have happened in the Perl4->5
migration some years ago. Could happen again.
-- Aaron Watters
===
http://www.xfeedme.com/nucular/pydistro.py/go?FREETEXT=repeatedly+hammer
Rhamphoryncus
> On Apr 16, 1:42 pm, Rhamphoryncus <rha...@gmail.com> wrote:
>
> > The only reason to not make the
> > changes is that old, crufty, unmaintained libraries & applications
> > might depend on them somehow. If that's more important to you, what
> > you really want is a language who's specs are frozen - much like C
> > effectively is. I hope python doesn't become that for a long time
> > yet, as there's too much it could do better.
>
> I'm feeling a bit old, crufty, and unmaintained myself,
> but I'll try not to take offense.
No offence meant, even if you do seem a bit set in your ways. ;)
> There is a difference between something that works fine
> until the rug gets pulled out and something that needs fixing.
> It's a shame to junk stuff that works.
The point is, you can't have it both ways. Either you evolve the
language and break things, or you keep it static and nothing breaks.
In the case of users wanting new versions, they may depend on the very
changes that break your libraries. There's no solution to that.
> Also in the case of C/java etc changing the infrastructure
> is less scary because you usually find out about problems
> when the compile or link fails. For Python you may not find
> out about it until the program has been run many times.
> Perhaps this will inspire improved linters and better coding
> practices....
Better coding practises such as extensive unit tests?
> I suppose if the py3k migration inspires tons of
> insomniac young programmers to seek fame and admiration
> by cleaning up ancient libraries, it would be a good
> thing. It seems to have happened in the Perl4->5
> migration some years ago. Could happen again.
If they're unmaintained, absolutely, it'd be great for them to get new
maintainers.
Aaron Watters
> The point is, you can't have it both ways. Either you evolve the
> language and break things, or you keep it static and nothing breaks.
I disagree. You can add lots of cool
stuff without breaking the existing code base, mostly.
For example the minor changes to the way ints will work will
effect almost no programs.
I don't see the urgency to clean up what are essentially
cosmetic issues and throw out or
require rewrites for just about all existing Python
code. Python 2.6 isn't fundamentally awful like Perl 4 was.
The cost paid for these minor improvements is too high in my
book. But I suppose if it is going to happen do it sooner
rather than later. Just *please* *please* don't
systematically break the pre-existing code base again for a
very long time, preferable ever.
-- Aaron Watters
===
http://www.xfeedme.com/nucular/pydistro.py/go?FREETEXT=whack
Gabriel Genellina
<aaron....@gmail.com> escribió:
> On Apr 16, 11:15 am, Gabriel Genellina <gagsl-...@yahoo.com.ar> wrote:
>> On 16 abr, 09:56, Aaron Watters <aaron.watt...@gmail.com> wrote:
>>
>> > In my opinion python's adherence to backwards compatibility
>> > has been a bit mythological anyway -- many new python versions
>> > have broken my old code for no good reason. This is an irritant
>> > when you have thousands of users out there who suddenly drop
>> > your code, blame you and python, and move on to use something else.
> Yes I mean it. Actually I was unaware
> of/forgot reconvert, but it doesn't
> matter because it doesn't solve the problem of code I wrote that
> has long ago escaped into the wild no longer working. There are
> other examples too, having to do with things as simple as a name
> change in a standard module that broke old
> code of mine for what I regard as silly cosmetic reasons.
Yes, there was some cases like that in the past, but I think that now
there is a strict policy for backwards compatibility, including at least
one .n release with deprecation warnings before removing old things.
Anyway, sometimes incompatible changes appear in the standard library -
perhaps because less developers are looking at them in detail?
> I hope you are right about py3k conversions being pain
> free and routine. I'm suspicious about it however.
Well, I would not say "pain free", but certainly it's not as terrible as
some people imply...
--
Gabriel Genellina
Aaron Watters
> > Also in the case of C/java etc changing the infrastructure
> > is less scary because you usually find out about problems
> > when the compile or link fails. For Python you may not find
> > out about it until the program has been run many times.
> > Perhaps this will inspire improved linters and better coding
> > practices....
>
Greetings from Earth. What planet are you from? :)
There is always the possibility that frustrated
programmers will decide that "using something other
than python" is a "better coding practice". I've seen
it happen.
-- Aaron Watters
===
http://www.xfeedme.com/nucular/pydistro.py/go?FREETEXT=alien
sjde...@yahoo.com
> I disagree. You can add lots of cool
> stuff without breaking the existing code base, mostly.
> For example the minor changes to the way ints will work will
> effect almost no programs.
Wow, I'd venture that the division changes with ints are the only
thing I'm really concerned about breaking in 3.0, both because they're
more likely to slip by without being immediately noticed and because
they're likely to be foreign going forward for people used to C-style
integer division (ie most of the programmers in our office). Even
them I don't see as a huge roadblock, but a "erase old ways of
thinking" bugaboo for a while.
But the rest of the changes are pretty obvious and well warned about
by 2to3 and the interpreter.
Rhamphoryncus
> On Apr 16, 2:33 pm, Rhamphoryncus <rha...@gmail.com> wrote:
>
> > The point is, you can't have it both ways. Either you evolve the
> > language and break things, or you keep it static and nothing breaks.
>
> I disagree. You can add lots of cool
> stuff without breaking the existing code base, mostly.
> For example the minor changes to the way ints will work will
> effect almost no programs.
What changes are minor though? Eliminating old-style classes should
be minor, but I'm not sure it is. Applications & libraries have a way
of depending on the most obscure details - even if trivially fixed, it
still requires a fix. Consider "as" becoming a keyword, or True and
False.
In hindsight, it would have been better to add future imports for
unicode literals and print-as-a-function back in 2.5. I guess the
time machine was out of service. 2.6 will have to do (and that's what
it's for.)
I'm personally not too worried about the syntax changes though,
they're superficial(!). What I am worried about is the library APIs
changing to use unicode instead of bytes. It's not something you
could do incrementally without providing two of every lib or two of
every API - having .write() and .writeex() would suck.
Marc 'BlackJack' Rintsch
>> > Perhaps this will inspire improved linters and better coding
>> > practices....
>>
>> Better coding practices such as extensive unit tests?
>
> Greetings from Earth. What planet are you from? :)
>
> There is always the possibility that frustrated
> programmers will decide that "using something other
> than python" is a "better coding practice". I've seen
> it happen.
So the average quality of Python coders raises. Cool. ;-)
Ciao,
Marc 'BlackJack' Rintsch
Steve Holden
I'm pretty sure the 3.0 compatibility breakage is a one-shot deal. If
it's not I won't be the only one looking for Guido with a bog stick in
my hand ...
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
Steve Holden
I'm pretty sure the 3.0 compatibility breakage is a one-shot deal. If
Donn Cave
Steve Holden <st...@holdenweb.com> wrote:
> Aaron Watters wrote:
> > The cost paid for these minor improvements is too high in my
> > book. But I suppose if it is going to happen do it sooner
> > rather than later. Just *please* *please* don't
> > systematically break the pre-existing code base again for a
> > very long time, preferable ever.
>
> I'm pretty sure the 3.0 compatibility breakage is a one-shot deal. If
> it's not I won't be the only one looking for Guido with a bog stick in
> my hand ...
Depending on what you mean, that appears to be either a
truism or an absurdity. If you mean, 3.1 won't break
code like 3.0 did ... well, of course. If you mean, there
won't be a 4.0 that means the same thing for compatibility
that 3.0 means, then I can't imagine how you could be
convinced of this. Changes to Python in 3.0 won't satisfy
the continuing "need" for change thereafter.
Donn Cave, do...@u.washington.edu
Carl Banks
> On Apr 16, 12:27 pm, Rhamphoryncus <rha...@gmail.com> wrote:
>
> > On Apr 16, 6:56 am, Aaron Watters <aaron.watt...@gmail.com> wrote:
>
> > > I don't get it. It ain't broke. Don't fix it.
>
> > So how would you have done the old-style class to new-style class
> > transition?
>
> I'd ignore it. I never understood it and never had
> any need for it anyway. New-style classes and metaclasses
> were a complicated solution to an unimportant problem in
> my opinion. And also a fiendish way to make code
> inscrutible -- which I thought was more of a Perl thing
> than a Python thing, or should be.
>
> I must be missing some of the deeper issues here. Please
> educate me.
The deeper issue is that you're benefiting from these "unimportant"
changes even if you never use them yourself.
Carl Banks
Sverker Nilsson
That just seems a BIT categorical for a statement. Who is 'you'?
I don't see I benefit from any important or unimportant features in
py3k.
External libraries I rely on, I can benefit from ---
But it would take SOME while to get those libraries ported to py3k, if
ever.
And I have been benefiting from Python in general, so far. Thanks,
community.
But now... I'll probably stop posting here for now, & I may stop other
things too.
Just my 2c.
Sverker
Sverker Nilsson
That just seems a BIT categorical for a statement. Who is 'you'?
Paul Boddie
>
> Do you mean Ruby's track in providing backward compatibility is better
> than Python's?
>
> Googling for that a bit, I would reckon otherwise.
So would I, but then it isn't the Ruby developers that are *promising*
to break backward compatibility *and* claiming that it's a good thing.
This means that those wanting to sell Ruby as a solution can play the
political game and claim a better roadmap even if they end up causing
more disruption than Python 3.x does: it's like electioneering on a
platform of "no new taxes" and then breaking that promise after
gaining power.
I find myself agreeing strongly with Aaron about this. Lots of things
were considered "wrong" with Python over the years, but I'm
unconvinced about the remedy:
http://wiki.python.org/moin/PythonWarts
There seems to be a lot of "out with the old" in the Free Software
world of late. Another example: KDE 3.x eventually finds itself in
products with widespread distribution; the developers bring out a less
capable version (but with more "bling") that everyone is now
supposedly working on instead; momentum is lost.
Paul
Carl Banks
> On Apr 17, 12:02 am, Carl Banks <pavlovevide...@gmail.com> wrote:
>
>
>
> > On Apr 16, 12:40 pm, Aaron Watters <aaron.watt...@gmail.com> wrote:
>
> > > On Apr 16, 12:27 pm, Rhamphoryncus <rha...@gmail.com> wrote:
>
> > > > On Apr 16, 6:56 am, Aaron Watters <aaron.watt...@gmail.com> wrote:
>
> > > > > I don't get it. It ain't broke. Don't fix it.
>
> > > > So how would you have done the old-style class to new-style class
> > > > transition?
>
> > > I'd ignore it. I never understood it and never had
> > > any need for it anyway. New-style classes and metaclasses
> > > were a complicated solution to an unimportant problem in
> > > my opinion. And also a fiendish way to make code
> > > inscrutible -- which I thought was more of a Perl thing
> > > than a Python thing, or should be.
>
> > > I must be missing some of the deeper issues here. Please
> > > educate me.
>
> > The deeper issue is that you're benefiting from these "unimportant"
> > changes even if you never use them yourself.
>
> > Carl Banks
>
> That just seems a BIT categorical for a statement. Who is 'you'?
The Python community, more or less. The person I was replying to,
specifically.
> I don't see I benefit from any important or unimportant features in
> py3k.
I was talking about the features added in 2.x. Python 3.0 features
haven't benefited many people (yet).
[snip]
> Just my 2c.
If you don't mind me saying, I think you've given us quite a bit more
than 2c in this thread.
Carl Banks
Aaron Watters
>
> Wow, I'd venture that the division changes with ints are the only
Oh I forgot about this one. Yes, I think it's a mistake to
adopt a different convention for division than C/C++/java/C#/Fortran/
Basic...
Just another reason to throw your hands up in frustration, in my
book...
The implications of the string conversion is entirely unclear to me.
I'm betting the libraries will also get "improved" during porting,
either intentionally or accidentally
which means I'll have to carefully rewrite
and retest any code which uses the
new and improved libraries ... and the "deprecated/removed"
libs won't work anymore, so I can't just put them into
my package...
sigh.
-- Aaron Watters
===
http://www.xfeedme.com/nucular/pydistro.py/go?FREETEXT=sigh
Michael Torrie
> What I'm saying is that, for example, there are a lot
> of cool tools out there for using Python to manipulate
> postscript and latex and such. Most of those tools
> require no maintenance, and the authors are not paying
> any attention to them, and they aren't interested in
> messing with them anymore.
What makes you think these tools are all going to mysteriously stop
working? Python 2.x will be around for a long, long time. Currently
there are still Python 1.5 apps that are still in use and circulation
and, with Python 1.5 installed, still work fine. The same for Python
2.x. Honestly I don't understand all this FUD over the move to Python
3.x Those that want/need to migrate will. Others won't have to.
What's the big deal?
Further, 90% of these little, finished utilities are pure python, and so
converting them to Python 3.x is a trivial mechanical conversion if the
maintainer cared.
Diez B. Roggisch
> community.
>
> But now... I'll probably stop posting here for now, & I may stop other
> things too.
>
> Just my 2c.
You know what I was just wondering about? All these C-written
cross-platform libraries (which Python users benefit from, most probably
including evven you) that run on different unixes & windows, which are a
much greater diversity to handle than the not-even-yet-settled
differences between Py3K & 2.x. How the heck do they do that?
Oh, and these dreaded 64 bit processors, possibly with multi-cores,
which need changes in code as well, to be utilized to their power.
But then, these guys most probably don't whine about diversity and
constant change, and cry out useless threats to people who probably
can't care less.
Fare well, if you must. But getting mad over something which impact you
can't even judge right now is childish. Nothing else.
Diez
John Machin
At the start of this thread I was pondering the possible meaning of the
verb "to sverk". Thanks for the exposition, Diez.
Sverker Nilsson
Some whine. Some just don't care. Why not whine?
Sverker Nilsson
Yah, and I am getting all the more depressed.
Thanks?
Juergen Kareta
Robin Becker
.
> You know what I was just wondering about? All these C-written
> cross-platform libraries (which Python users benefit from, most probably
> including evven you) that run on different unixes & windows, which are a
> much greater diversity to handle than the not-even-yet-settled
> differences between Py3K & 2.x. How the heck do they do that?
I'm in the process of attempting a straightforward port of a relatively simple
package which does most of its work by writing out files with a more or less
complicated set of possible encodings. So far I have used all the 2to3 tools and
a lot of effort, but still don't have a working version. This must be the worst
way to convert people to unicode. When tcl went through this they chose the
eminently sensible route of not choosing a separate unicode type (they used utf8
byte strings instead). Not only has python chosen to burden itself with two
string types, but with 3 they've swapped roles. This is certainly the first time
I've had to decide on an encoding before writing simple text to a file.
Of course we may end up with a better language, but it will be a worse(more
complex) tool for many simple tasks. Using a complex writing with many glyphs
costs effort no matter how you do it, but I just use ascii :( and it's still an
effort.
I find the differences in C/OS less hard to understand than why I need
bytes(x,'encoding') everywhere I just used to use str(x).
-old fart-ly yrs-
Robin Becker
Diez B. Roggisch
> I'm in the process of attempting a straightforward port of a relatively
> simple package which does most of its work by writing out files with a
> more or less complicated set of possible encodings. So far I have used
> all the 2to3 tools and a lot of effort, but still don't have a working
> version. This must be the worst way to convert people to unicode. When
> tcl went through this they chose the eminently sensible route of not
> choosing a separate unicode type (they used utf8 byte strings instead).
> Not only has python chosen to burden itself with two string types, but
> with 3 they've swapped roles. This is certainly the first time I've had
> to decide on an encoding before writing simple text to a file.
Which is the EXACT RIGHT THING TO DO! see below.
>
> Of course we may end up with a better language, but it will be a
> worse(more complex) tool for many simple tasks. Using a complex writing
> with many glyphs costs effort no matter how you do it, but I just use
> ascii :( and it's still an effort.
>
> I find the differences in C/OS less hard to understand than why I need
> bytes(x,'encoding') everywhere I just used to use str(x).
If you google my name + unicode, you see that I'm often answering
questions regarding unicode. I wouldn't say I'm a recognized expert on
the subject, but I certainly do know enough to deal with it whenever I
encounter it.
And from my experience with the problems in general, and specificly in
python, as well as trying to help others I can say that:
- 95% of the times, the problem is in front of the keyboard.
- programmers stubbornly refuse to *learn* what unicode is, and what
an encoding is, and what role utf-8 plays. Instead, the resort to a
voodoo-approach of throwing in various encode/decode-calls + a good deal
of cat's feces in hope of wriggling themselves out of the problem.
- it is NOT sensible to use utf8 as unicode-"type" - that is as bad as
it can get because you don't see the errors, but instead mangle your
data and end up with a byte-string-mess. If that is your road to heaven,
by all means chose it - and don't use unicode at all. and be prepared
for damnation :)
If your programs worked for now, but don't do anymore because of Py3K
introducing mandatory unicode-objects for string-literals it pretty much
follows that they *seem* to work, but very, very probably fail in the
face of actual i18nized data.
The *only* sensible thing to do is follow these simple rules - and these
apply with python 2.x, and will be enforced by 3k which is a good thing
IMHO:
- when you read data from somewhere, make sure you know which encoding
it has, and *immediatly* convert it to unicode
- when you write data, make sure you know which encoding you want it
to have (in doubt, chose utf-8 to prevent loss of data) and apply it.
- XML-parsers take byte-strings & spit out unicode. Period.
I neither want to imply that you are an Idiot nor that unicode doesn't
have it's complexities. And I'd love to say that Python wouldn't add to
these by having two string-types.
But the *real* problem is that it used to have only bytestrings, and
finally Py3K will solve that issue.
Diez
Istvan Albert
> Some whine. Some just don't care. Why not whine?
Whining and ranting is actually good for the psyche. It is better to
get it out of your system.
As for your original post, no doubt there are substantial downsides to
introducing Py3K, but as Guido put it every language must "change or
die".
Of course we could end up with "change and die" as well. I for one am
an optimist, I think there are several substantial improvements to the
language that today may not be apparent for a casual observer, yet
will allow it to evolve into an even more powerful and fun language
i.
Aaron Watters
> What's the big deal?
The big deal is that I would love to see Django
become the standard platform for web development,
for example. That will be much less likely if
60% of the contributed tools for Django don't work
for Python 3000 and 20% don't work for Python 2.6.
Expecting volunteer contributors
to support both is not realistic. It's hard enough
to support one adequately. Even if you could hope
to support both with the same code, just testing in
both environments would be onerous.
It would be another matter entirely if py3k offered
major new functionality like full stackless microthreads
but it doesn't (afaik -- correct me please).
From my perspective it's just a pain in the @$$.
By the way, full stackless microthreads don't seem
to require breaking most (or any) existing code.
I really like developing in Python -- but it's hard
to keep doing it when the growth curve is so slow
and a so many people have deep reservations about it,
inspired in part, justifiably, by nonsense like this.
In fact, I basically stopped. Then I came back. Now
I'm wondering if it was such a good idea...
-- Aaron Watters
====
http://www.xfeedme.com/nucular/pydistro.py/go?FREETEXT=stupid+bug
Ivan Illarionov
> The big deal is that I would love to see Django become the standard
> platform for web development, for example. That will be much less
> likely if 60% of the contributed tools for Django don't work for Python
> 3000 and 20% don't work for Python 2.6. Expecting volunteer contributors
> to support both is not realistic. It's hard enough to support one
> adequately. Even if you could hope to support both with the same code,
> just testing in both environments would be onerous.
You shouldn't worry about Django. Python 3000 port has already started
[1]. And the assumption that "to support both is not realistic" may be
wrong [2] in this case.
[1] http://wiki.python.org/moin/PortingDjangoTo3k
[2] http://groups.google.com/group/django-developers/msg/91f399820ee07ce5
--
Ivan
Nick Stinemates
> do i dare to open a thread about this?
>
> come on you braver men
>
> we are at least not bought by g***le
>
> but why? others have said it so many times i think
>
> :-////
>
> but why? a few syntactic 'cleanups' for the cost of a huge rewrite of
> all the code that have been builtup from all the beginning when the
> once great Python came along and people began to use it and write code
> for it. Like all that code would have to be rewritten. blaah.
> and i have perhaps been drinking but i have been p**d all week since i
> began look into this:-(
> --
> http://mail.python.org/mailman/listinfo/python-list
Yo, no one here is a child so don't litter your title and text with hard
to read bullshit.
--
Nick Stinemates (ni...@stinemates.org)
http://nick.stinemates.org
Jean-Paul Calderone
> [snip]
>
>Yo, no one here is a child
Hi Nick,
Actually, there are a number of young people on the list. So let's keep things
civil and try to avoid using harsh language.
Thanks!
Jean-Paul