Why Python 3?

[A.T.Hofkamp]

On 2007-12-05, Chris Gonnerman <chris.gonnerman at newcenturycomputers.net> wrote:
> 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