On 2007-12-05, Chris Gonnerman <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
