468,167 Members | 1,924 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,167 developers. It's quick & easy.

py3k s***s

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:-(
Jun 27 '08 #1
59 1573
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
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:-(
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/

Jun 27 '08 #2
Sverker Nilsson <sn@sncs.sewrites:
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
Jun 27 '08 #3
On Apr 14, 8:10*pm, Sverker Nilsson <s...@sncs.sewrote:
do i dare to open *a thread about this?
Yeah, you sure do!
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
Jun 27 '08 #4
On Apr 15, 1:34 am, Steve Holden <st...@holdenweb.comwrote:
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 have sobered up abit, it doesnt matter much

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

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:-(

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/
Jun 27 '08 #5
On Apr 15, 2:58 am, ajaksu <aja...@gmail.comwrote:
On Apr 14, 8:10 pm, Sverker Nilsson <s...@sncs.sewrote:do i dare to open a thread about this?

Yeah, you sure do!
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
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
Jun 27 '08 #6
En Mon, 14 Apr 2008 22:02:38 -0300, Sverker Nilsson <sn@sncs.seescribió:
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

Jun 27 '08 #7
On Apr 15, 2:58 am, ajaksu <aja...@gmail.comwrote:
On Apr 14, 8:10 pm, Sverker Nilsson <s...@sncs.sewrote:do i dare to open a thread about this?

Yeah, you sure do!
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
What serious reports?

Jun 27 '08 #8
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.seescribió:
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
Jun 27 '08 #9
En Mon, 14 Apr 2008 23:38:56 -0300, Sverker Nilsson <sn@sncs.seescribió:
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.

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. :-(
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

Jun 27 '08 #10
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

Sverker
On Apr 15, 5:41 am, "Gabriel Genellina" <gagsl-...@yahoo.com.ar>
wrote:
En Mon, 14 Apr 2008 23:38:56 -0300, Sverker Nilsson <s...@sncs.seescribió:
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.
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. :-(

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
Jun 27 '08 #11
En Tue, 15 Apr 2008 01:30:05 -0300, Sverker Nilsson <sn@sncs.seescribió:
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

Jun 27 '08 #12
On Apr 14, 11:07*pm, Sverker Nilsson <s...@sncs.sewrote:
What serious reports?
You almost had me collecting a list of reports/references. Almost :)

Google and you'll find them.

Regards,
Daniel
Jun 27 '08 #13
Sverker Nilsson wrote:
[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
fork TWO codes. [...]
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
Jun 27 '08 #14

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
On Apr 15, 5:41 am, "Gabriel Genellina" <gagsl-...@yahoo.com.ar>
wrote:
>En Mon, 14 Apr 2008 23:38:56 -0300, Sverker Nilsson <s...@sncs.se
escribió:
>>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.
>>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. :-(

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.
Jun 27 '08 #15
Chris McAloney wrote:
*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.

Jun 27 '08 #16
In article
<11**********************************@p25g2000hsf. googlegroups.com>,
Sverker Nilsson <sn@sncs.sewrote:
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
Jun 27 '08 #17

"Sverker Nilsson" <sn@sncs.sewrote in message
news:ed**********************************@m44g2000 hsc.googlegroups.com...
| What serious reports?

http://wiki.python.org/moin/Early2to3Migrations

Jun 27 '08 #18
Thanks for your well-formulated article

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.eduwrote:
In article
<11567a1a-b184-42e6-bbf3-a655736c1...@p25g2000hsf.googlegroups.com>,
Sverker Nilsson <s...@sncs.sewrote:
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, d...@u.washington.edu
Jun 27 '08 #19
To be frank, no innovation. Just changes, no progress. And yes, I am
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
Jun 27 '08 #20
On Apr 15, 12:30 am, Sverker Nilsson <s...@sncs.sewrote:
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/pydis...ETEXT=nonsense
Jun 27 '08 #21
Aaron Watters wrote:
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.
Jun 27 '08 #22
On Apr 16, 9:16 am, Marco Mariani <ma...@sferacarta.comwrote:
>
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/pydis...eap+dead+child
Jun 27 '08 #23
On 16 abr, 09:56, Aaron Watters <aaron.watt...@gmail.comwrote:
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?

pyimport reconvert
pyhelp(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
Jun 27 '08 #24
On 15 abr, 13:58, Michael Torrie <torr...@gmail.comwrote:
>
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
Jun 27 '08 #25
On Apr 16, 11:15 am, Gabriel Genellina <gagsl-...@yahoo.com.arwrote:
On 16 abr, 09:56, Aaron Watters <aaron.watt...@gmail.comwrote:
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?

pyimport reconvert
pyhelp(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/pydis...EXT=cause+pain
Jun 27 '08 #26
In article
<cf**********************************@l42g2000hsc. googlegroups.com>,
Aaron Watters <aa***********@gmail.comwrote:
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
Jun 27 '08 #27
On Apr 16, 6:56 am, Aaron Watters <aaron.watt...@gmail.comwrote:
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?
Jun 27 '08 #28
On Apr 16, 12:27 pm, Rhamphoryncus <rha...@gmail.comwrote:
On Apr 16, 6:56 am, Aaron Watters <aaron.watt...@gmail.comwrote:
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.
-- Aaron Watters
===

http://www.xfeedme.com/nucular/pydis...=killer%20joke
Jun 27 '08 #29
On Wed, Apr 16, 2008 at 11:40 AM, Aaron Watters <aa***********@gmail.comwrote:
On Apr 16, 12:27 pm, Rhamphoryncus <rha...@gmail.comwrote:
On Apr 16, 6:56 am, Aaron Watters <aaron.watt...@gmail.comwrote:
>
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.
Jun 27 '08 #30
On Apr 16, 10:40 am, Aaron Watters <aaron.watt...@gmail.comwrote:
On Apr 16, 12:27 pm, Rhamphoryncus <rha...@gmail.comwrote:
On Apr 16, 6:56 am, Aaron Watters <aaron.watt...@gmail.comwrote:
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.
Jun 27 '08 #31
On Apr 16, 1:42 pm, Rhamphoryncus <rha...@gmail.comwrote:
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/pydis...eatedly+hammer
Jun 27 '08 #32
On Apr 16, 12:10 pm, Aaron Watters <aaron.watt...@gmail.comwrote:
On Apr 16, 1:42 pm, Rhamphoryncus <rha...@gmail.comwrote:
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.
Jun 27 '08 #33
On Apr 16, 2:33 pm, Rhamphoryncus <rha...@gmail.comwrote:
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/pydis...FREETEXT=whack
Jun 27 '08 #34
En Wed, 16 Apr 2008 13:09:05 -0300, Aaron Watters
<aa***********@gmail.comescribió:
On Apr 16, 11:15 am, Gabriel Genellina <gagsl-...@yahoo.com.arwrote:
>On 16 abr, 09:56, Aaron Watters <aaron.watt...@gmail.comwrote:
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

Jun 27 '08 #35
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 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.

-- Aaron Watters

===
http://www.xfeedme.com/nucular/pydis...FREETEXT=alien

Jun 27 '08 #36
On Apr 16, 2:52 pm, Aaron Watters <aaron.watt...@gmail.comwrote:
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.
Jun 27 '08 #37
On Apr 16, 12:52 pm, Aaron Watters <aaron.watt...@gmail.comwrote:
On Apr 16, 2:33 pm, Rhamphoryncus <rha...@gmail.comwrote:
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.
Jun 27 '08 #38
On Wed, 16 Apr 2008 12:32:00 -0700, Aaron Watters wrote:
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
Jun 27 '08 #39
Aaron Watters wrote:
On Apr 16, 2:33 pm, Rhamphoryncus <rha...@gmail.comwrote:
>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.
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/
Jun 27 '08 #40
Aaron Watters wrote:
On Apr 16, 2:33 pm, Rhamphoryncus <rha...@gmail.comwrote:
>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.
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/

Jun 27 '08 #41
In article <ma**************************************@python.o rg>,
Steve Holden <st***@holdenweb.comwrote:
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
Jun 27 '08 #42
On Apr 16, 12:40 pm, Aaron Watters <aaron.watt...@gmail.comwrote:
On Apr 16, 12:27 pm, Rhamphoryncus <rha...@gmail.comwrote:
On Apr 16, 6:56 am, Aaron Watters <aaron.watt...@gmail.comwrote:
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
Jun 27 '08 #43
On Apr 17, 12:02 am, Carl Banks <pavlovevide...@gmail.comwrote:
On Apr 16, 12:40 pm, Aaron Watters <aaron.watt...@gmail.comwrote:
On Apr 16, 12:27 pm, Rhamphoryncus <rha...@gmail.comwrote:
On Apr 16, 6:56 am, Aaron Watters <aaron.watt...@gmail.comwrote:
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'?

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
Jun 27 '08 #44
On Apr 17, 12:02 am, Carl Banks <pavlovevide...@gmail.comwrote:
On Apr 16, 12:40 pm, Aaron Watters <aaron.watt...@gmail.comwrote:
On Apr 16, 12:27 pm, Rhamphoryncus <rha...@gmail.comwrote:
On Apr 16, 6:56 am, Aaron Watters <aaron.watt...@gmail.comwrote:
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'?

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
Jun 27 '08 #45
On 16 Apr, 15:16, Marco Mariani <ma...@sferacarta.comwrote:
>
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
Jun 27 '08 #46
On Apr 17, 4:41 am, Sverker Nilsson <s...@sncs.sewrote:
On Apr 17, 12:02 am, Carl Banks <pavlovevide...@gmail.comwrote:
On Apr 16, 12:40 pm, Aaron Watters <aaron.watt...@gmail.comwrote:
On Apr 16, 12:27 pm, Rhamphoryncus <rha...@gmail.comwrote:
On Apr 16, 6:56 am, Aaron Watters <aaron.watt...@gmail.comwrote:
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
Jun 27 '08 #47
On Apr 16, 3:33 pm, "sjdevn...@yahoo.com" <sjdevn...@yahoo.comwrote:
>
Wow, I'd venture that the division changes with ints are the only
thing I'm really concerned about...
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/pydis...?FREETEXT=sigh
Jun 27 '08 #48
Aaron Watters wrote:
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.
Jun 27 '08 #49
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.
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
Jun 27 '08 #50

This discussion thread is closed

Replies have been disabled for this discussion.

By using this site, you agree to our Privacy Policy and Terms of Use.