Why Python 3?

[Terry Reedy]

"Chris Gonnerman" <chris.gonnerman at newcenturycomputers.net> wrote in
message news:47562B8A.3040506 at newcenturycomputers.net...
|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?

Overall, to delete accumulated stuff, much of which would have been deleted 
already if not for the prospect of Python3 and the decision to put off 
deletions until then.

|  Why bother to change to Python 3, when the CPython
| implementation is slower, and probably will be for a while?

Guido's philosophy is to get it right first and then speed it up.  I would 
not judge the future 3.0 final by the current alpha1.

| But... almost all of my old 1.5 code ported painlessly to 2.x.
| No need for a "1.5to2" script,

That is because deletion of obsolete features has been put off until 3.0 
instead of being done release by release, as was the policy once, until 
people persuaded Guido to bunch up code-breaking changes.

Also, 2.0 would have been 1.6.1 or 1.7 but for legal and political reasons 
related to the change of venue.  Similarly, 2.1 would have been 1.7 or 1.8.

2.2, with iterators and new-style classes should have been 2.0.  That was 
the real break.  But old-style classes were kept for the 2.x series even 
though they make learning, maintenance, and upgrades a bit harder.

|  whereas I see that there is a "2to3" script for converting modules.

If stuff were deleted (or incompatibly changed) every release, people would 
want a converter script for every release.  I believe the idea may have 
arisen in the discussion of redefining int/int.  Changing that from 
'future' to 'present' has been put off much longer than originally planned.

|  Python 1.5 and 2.x are "executable pseudocode,"
| something that can be easily read by anyone with a modicum of
| programming knowledge.

The subset of 3.0 that is basically the same as 1.4, the version for which 
I coined that phrase, still should be.

|  In fact, the things I rarely or never use in
| Python tend to be those things I find hardest to read (like list
| comprehensions).

Yes, I have thought about whether I should use l.c.s in didactic programs 
primarily meant for human readers who are not necessarily Python 
programmers.

|  Few of the changes along the way have required me to
| change how I *write* code;

Because most code-breaking changes that would have required you to change 
have been put off to 3.0.

| probably the worst was the integer division
| change, which I disagreed with, but I went along with the community.

But that change has not happened yet (without a future import) -- because 
it was put off to 3.0.  Learning Python today would be easier if int/int 
did *not* still have two possible meanings, and it will be easier when the 
change is complete.


I see four possible policies with respect to replacing features with 
intended improvements.

A. Never do it, so there is never a reason to delete anything.

B. Add new versions of a feature but keep the old version also forever.

C Add new versions and delete the old soon after.

D. Add new versions but delete the old in a bunch after several additions.


Terry Jan Reedy