py3k s***s

[Michael Torrie]

Re: py3k s***s

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.

[Donn Cave]

Re: py3k s***s

In article
<11567a1a-b184-42e6-bbf3-a655736c19c7@p2 5g2000hsf.googl egroups.com>,
Sverker Nilsson <sn@sncs.sewrot e:

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, donn@u.washingt on.edu

[Terry Reedy]

Re: py3k s***s


"Sverker Nilsson" <sn@sncs.sewrot e in message
news:eda75e1a-904e-4916-9489-934cb679a516@m4 4g2000hsc.googl egroups.com...
| What serious reports?

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

[Sverker Nilsson]

Re: py3k s***s

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.washing ton.eduwrote:

In article
<11567a1a-b184-42e6-bbf3-a655736c1...@p2 5g2000hsf.googl egroups.com>,
Sverker Nilsson <s...@sncs.sewr ote:
>

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.washingt on.edu

[Damjan]

Re: py3k s***s

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

[Aaron Watters]

Re: py3k s***s

On Apr 15, 12:30 am, Sverker Nilsson <s...@sncs.sewr ote:

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]

Re: py3k s***s

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.

[Aaron Watters]

Re: py3k s***s

On Apr 16, 9:16 am, Marco Mariani <ma...@sferacar ta.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/pydistro.py/go?FREETEXT=reap+dead+child

[Gabriel Genellina]

Re: py3k s***s

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(reconver t)
Help on module reconvert:

NAME
reconvert - Convert old ("regex") regular expressions to new
syntax ("re").

FILE
c:\apps\python2 4\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 incompatibiliti es 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 incompatibiliti es 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_literal s" 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]

Re: py3k s***s

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

[Aaron Watters]

Re: py3k s***s

On Apr 16, 11:15 am, Gabriel Genellina <gagsl-...@yahoo.com.a rwrote:

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(reconver t)...

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]

Re: py3k s***s

In article
<cf36d4f6-11be-4788-a38e-a990b6a90df5@l4 2g2000hsc.googl egroups.com>,
Aaron Watters <aaron.watters@ 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, donn@u.washingt on.edu

[Rhamphoryncus]

Re: py3k s***s

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?

[Aaron Watters]

Re: py3k s***s

On Apr 16, 12:27 pm, Rhamphoryncus <rha...@gmail.c omwrote:

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/pydistro.py/go?FREETEXT=killer%20joke

[Chris Mellon]

Re: py3k s***s

On Wed, Apr 16, 2008 at 11:40 AM, Aaron Watters <aaron.watters@ gmail.comwrote:

On Apr 16, 12:27 pm, Rhamphoryncus <rha...@gmail.c omwrote:

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.