"Chris Gonnerman" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] |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 -- http://mail.python.org/mailman/listinfo/python-list