Why Python 3?

[Chris Gonnerman]

I spent some time today reading about Python 3, and specifically the
differences between Python 3 and Python 2, and I was left with a
question... why? Why bother to change to Python 3, when the CPython
implementation is slower, and probably will be for a while?

When I learned Python, 1.5 was the current version. Each new version
from 2.0 on brought goodies to the table... I think I have made use of
about half of the "advancements" that have come along since. But I was
swayed into taking Python seriously by Eric Raymond's article in Linux
Journal, where he talked about how much easier it was to read his old
code in Python than in Perl, and how the whole white space thing wasn't
so bad. I discovered I agreed with him. Python has been my favorite
language ever since.

But... almost all of my old 1.5 code ported painlessly to 2.x. No need
for a "1.5to2" script, whereas I see that there is a "2to3" script for
converting modules. Python 1.5 and 2.x are "executable pseudocode,"
something that can be easily read by anyone with a modicum of
programming knowledge. In fact, the things I rarely or never use in
Python tend to be those things I find hardest to read (like list
comprehensions). Few of the changes along the way have required me to
change how I *write* code; probably the worst was the integer division
change, which I disagreed with, but I went along with the community.

I don't see myself using Python 3 for a long time. Probably as long as
I can hold out. Where are my goodies? What is my payoff for learning
how to write code the new way? I can't see it. Many things seem a lot
less obvious... like, what was wrong with <dict>.keys() returning a
list? Now it returns some strange object type.

I don't think I can surely be the only one. Certainly, I'm nobody
important; it's not as if my opinion has any real bearing on the
situation. I suspect that many Python coders will stay with 2.x; after
all, this is Open Source... there is no Micro$oft forcing us to upgrade
to get more licenses. If enough people stay with 2.x... will the
project fork? Will there be enough of "us" to maintain Python 2
indefinitely? Will module maintainers have to choose which version of
Python to support? It's already a pain for me to keep the GDmodule up
with the current Python release... and it's a pretty small module.

I just don't see the point. I feel like we already have all we need in
Python 2. I feel like the language is becoming less and less "friendly"
and "readable" as it evolves.

Just my two cents, I guess.

-- Chris Gonnerman

 

[Carl Banks]

On Dec 4, 11:39 pm, Chris Gonnerman

I don't think I can surely be the only one. Certainly, I'm nobody
important; it's not as if my opinion has any real bearing on the
situation. I suspect that many Python coders will stay with 2.x; after
all, this is Open Source... there is no Micro$oft forcing us to upgrade
to get more licenses. If enough people stay with 2.x... will the
project fork?

There's no need to get that concerned; Python 2.x will exist and be
maintained alongside Python 3.x for quite a while, probably 10 years.

FWIW: I think the Python 3 effort has done well to keep things from
getting out of hand; I expect transitions to be mostly smooth.
Probably the trickiest aspect of transition will be getting Unicode
and byte strings straight.


Carl Banks

 

[A.T.Hofkamp]

I spent some time today reading about Python 3, and specifically the
differences between Python 3 and Python 2, and I was left with a
question... why? Why bother to change to Python 3, when the CPython
implementation is slower, and probably will be for a while?

I think to preserve the smoothness of switching versions, like you do now.

As user, you can smoothly 'upgrade' to using new Python features in the pace
that you like. Unfortunately for the developers, not all users do that at the
same rate and switch to the same sub-set (and that is good, I think). As a
result, the developers have to be very backwards compatible. In other words,
you can probably run a lot of the Python 1.5.2 code you wrote several years ago
using today's Python 2.5. To make that possible, all 1.5.2 stuff is still in
today's Python 2.5 interpreter, even though there are not many users that code
in 1.5.2 style any more.

As you can imagine, this old stuff piles up as we progress in Python versions.
Python 3 is the breaking point where the old stuff (that (almost) nobody uses
any more, since everybody is using new coding styles) is really gone.
That gives room for a new design of the interpreter from the ground up, using
today's coding practices and ideas as starting point.


For you as user, the transition to Python 3 will probably be smooth too. Unless
you stopped reading about new Python versions after 1.5.2, and are still using
that old 1.5.2 book as ultimate Python reference, your coding style has changed
too towards newer Python versions (and ultimately towards Python 3).

In addition, knowing the Python development cycle, as the features of Python 3
become more clear, they will first be implemented in the Python 2.x range for
testing and for giving users the chance to already pick up the new coding
styles, so by the time the last 2.x version is retired, Python 3 will have
(almost) no sudden transitions for you.

But... almost all of my old 1.5 code ported painlessly to 2.x. No need
for a "1.5to2" script, whereas I see that there is a "2to3" script for

Well, Python 3 design is from the ground up, and aimed at the future, so they
are quite a few steps ahead of today's coding practice, let alone today's code
base (which is still 1.5 compatible as you discovered).
To run any form of practical experiments, one needs a way to quickly convert
the current code to the new conventions/ideas. Since programmers rather let the
computer do boring repetitive tasks, they write a script for the conversions.
Since Python is open source, you may also want to experiment with Python 3, and
in that case the script is very handy.

Imho, existence of such a script today does not automatically mean that you
will need to use a script at the moment you (or I) switch to Python 3.

programming knowledge. In fact, the things I rarely or never use in
Python tend to be those things I find hardest to read (like list
comprehensions). Few of the changes along the way have required me to

I use them a lot, and they are very powerful. On the other hand, I never use
generators, which is probably a loss for me.

change how I *write* code; probably the worst was the integer division

I think you change the way you write code continuously. I have been programming
computers for 20+ years, and are still changing the way I code.

change, which I disagreed with, but I went along with the community.

Some changes are for your own good, even though you do not realize it now
For you it is the integer division. For me, I have a problem with new-style
classes, where the __eq__ method is already implemented, blurring the
difference between 'is' and '=='.

Ah well, no language is perfect, and there is probably a very good reason for
the change even if I don't see it.
(and if there is really none, the change will be undone with Python 4... )

I don't see myself using Python 3 for a long time. Probably as long as
I can hold out. Where are my goodies? What is my payoff for learning
how to write code the new way? I can't see it. Many things seem a lot

A lot of the new goodies give you more punch per line, ie less lines to
express what you want to calculate. This is good, since the chance making an
error is a constant per line, so less lines is less errors.

less obvious... like, what was wrong with <dict>.keys() returning a
list? Now it returns some strange object type.

In addition, Python is generalizing programming. Why would you want to write a
for-loop yourself if you can push the loop into that strange object type? This
may look useless, but what actually happens here is that the level of
abstraction in programming is raised further (just like the main benefit of
switching from eg C to Python is the step up in abstraction (you get eg
dictionaries and lists built in, rather than having to program them yourself
from struct's for the umpteenth time).

Ultimately, when you start thinking in those new abstractions, you grow as
programmer.
(Think back to before you discovered Python. Would you have ever dreamed then
that you could express your computation like you do today using Python? The new
Python version is a continuation of that process.)

I don't think I can surely be the only one. Certainly, I'm nobody
important; it's not as if my opinion has any real bearing on the

Well, that's the down side of raising abstraction; the learning curve gets
longer or steeper. Also, with the increase in abstraction, the number of
differen uses grows (for loops can be used in only one way, generators can be
used in many different ways).
So, the community will diverse I think. Different people will use Python in
different ways with different sub-sets. (Like today, but more diverse.)

situation. I suspect that many Python coders will stay with 2.x; after

I think not. you changed from Python 1.5.2 to today. Why do you think you will
stop changing now?

all, this is Open Source... there is no Micro$oft forcing us to upgrade
to get more licenses. If enough people stay with 2.x... will the
project fork? Will there be enough of "us" to maintain Python 2

Yep, forking is always an option. Nobody is stopping you.

indefinitely? Will module maintainers have to choose which version of
Python to support? It's already a pain for me to keep the GDmodule up

I doubt it will ever come to this point.
Think what will happen. Suppose you thought 1.5.2 was the ultimate version, and
you forked the project at the release of 2.0 (well, the BDFL was adding all
these weird new features that you didn't want, what choice did you have?).

Do you think it is likely that you would still be using that exact version
today? I think not. Sooner or later one of the users would start adding that
one nice 2.x feature that is really handy for his problem.
Even if you explicitly forbid that (which is not possible by the way, that user
would then fork from your 1.5.2 project), what is 'development' or
'maintenance' with such a static version then? Just upgrading to eg a newer
gcc? If yes, then I think you will loose users very rapidly. A project will only
survive if you have something that is not elsewhere available.

I just don't see the point. I feel like we already have all we need in
Python 2. I feel like the language is becoming less and less "friendly"

I disagree here. You may think that you have all you need (just as you did
before discovering Python), but the world is changing continuously. For
example, dual-core systems are almost standard now. Wouldn't it be great to
have Python primitives that gives the tools to use that power? Tomorrow, we
have high bandwitdh everywhere, mobile distributed computing is standard. With
the current Python you won't get anywhere in that environment. (Not that I
think this will change any time soon by the way, we still don't understand how
to cope with the additional complexity.)

and "readable" as it evolves.

You may be right, you may be wrong. Nobody knows. One of the 'problems' of open
source is that development never ends. There is always yet another application
area that needs support, and some user will think, 'hey Python would be nice
here'...

Another 2 cents,
Albert

 

[Christian Heimes]

Well, Python 3 design is from the ground up, and aimed at the future, so they
are quite a few steps ahead of today's coding practice, let alone today's code
base (which is still 1.5 compatible as you discovered).

Just a small note from me:

Several people think that we are rewriting Python 3.0 from the scratch.
That is *not* correct. The 3.x series shares lots of code with the 2.x
series. We are still merging changes from the trunk (2.6) into the py3k
branch and we are going to backport several features from 3.0 into 2.6.

Some parts are of Python 3.0 are new and the majority of the rest is
just cleaned up a bit. Some new features like the new immutable bytes
type in 3.0a2 are mostly based on existing code.

At http://www.joelonsoftware.com/articles/fog0000000069.html Joel
explains why rewriting from the scratch is often the worst strategy.

Christian

 

[Kay Schluehr]

Athttp://www.joelonsoftware.com/articles/fog0000000069.htmlJoel
explains why rewriting from the scratch is often the worst strategy.

About migration strategies:

"I do not exactly recollect whether it was in Eastland or Jugemanland,
but I remember that in the midst of a dreary forest I spied a terrible
wolf making after me, with all the speed of ravenous winter hunger.

He soon overtook me. There was no possibility of escape. Mechanically
I laid myself down flat in the sledge, and let my horse run for our
safety. What I wished, but hardly hoped or expected, happened
immediately after. The wolf did not mind me in the least, but took a
leap over me, and falling furiously on the horse, began instantly to
tear and devour the hind-part of the poor animal, which ran the faster
for his pain and terror.

Thus unnoticed and safe myself, I lifted my head slyly up, and with
horror I beheld that the wolf had ate his way into the horse's body;
it was not long before he had fairly forced himself into it, when I
took my advantage, and fell upon him with the butt-end of my whip.

This unexpected attack in his rear frightened him so much, that he
leaped forward with all his might: the horse's carcase dropped on the
ground, but in his place the wolf was in the harness, and I on my part
whipping him continually: we both arrived in full career safe at St.
Petersburg, contrary to our respective expectations, and very much to
the astonishment of the spectators."

http://bulfinch.englishatheist.org/baron/Baron.html

 

[Michael Spencer]

This unexpected attack in his rear frightened him so much, that he
leaped forward with all his might: the horse's carcase dropped on the
ground, but in his place the wolf was in the harness, and I on my part
whipping him continually: we both arrived in full career safe at St.
Petersburg, contrary to our respective expectations, and very much to
the astonishment of the spectators."

http://bulfinch.englishatheist.org/baron/Baron.html

in order, I presume, to "counterpoint the surrealism of the underlying metaphor"

http://flag.blackened.net/dinsdale/dna/book1.html