For those of you don't know, Guido did a blog post on the status of Py3K. I suspect most people who keep up on Python stuff know about it at this point as it went far enough to get picked up by LtU. And reactions have varied from positive to negative.
I am not here to tell you about Guido's plans as the blog post covers that. I am also not here to say whether I like his plans as he has been taking input from people for quite some time and I have been part of the feedback-providing group for about as long (I am a co-author of PEP 3100 so I have been helping to make public what Guido keeps in his head for three years come August). I have blogged before about how I am a fan of Py3K and thus am putting my python-dev time into it.
What I am going to try to do with this post is publicly discuss some of the questions and comments I have come across that Guido's post has generated. As always, if this post doesn't answer your question, leave a comment and I will try to respond. And an important note for people who want to check out the Py3K code and play around: what Guido posted about are what is planned, not what is necessarily in the code!
The most common comment I have seen is about the removal of reduce from the built-ins. Now first of all, realize it is just being moved to functools, not being removed entirely. Hopefully that will calm some people down. Nor is this a sign that Python is going to suddenly cut out more and more functional programming support (I think the addition of set comprehensions in Py3K shows that is not the case).
But I think two things are important to understand for this. One is that whether you have wrapped your head around reduce so well that you don't need to write out the 'for' loop equivalent, that does not mean everyone else has. A lot of the defenders of reduce have been saying that once you get it it's a great little function. That's nice, but the stuff that are built-ins should not require practice to comprehend for the majority of people, especially beginners if it can be helped.
Nor should they require you to be into a style of programming that Python is not explicitly designed for. A commenter in the LtU post stated how Python might support functional programming, but it is not designed for it. That is an important point and means that the decision will not always be made from an FP perspective.
I am sure someone is now going, "but what about map and filter, why do they get to stay, can't you use list comprehensions?" The answer to that is simplicity; ``map(fxn, stuff)`` is simpler than ``[fxn(x) for x in stuff]`` (plus map is faster). And both functions are easy to comprehend and so they get to stay. Plus they are used a ton more than reduce is.
I have seen some people not liking ABCs, but it's just a library, so you don't have to use it if you don't want. I suspect a lot of people will just use it as a set of nice mixins to get some methods for free in certain circumstances. But for those who have a use for ABCs they will most likely appreciate it.
And then there are the usual suggestions on how to change the language that has been heard time again (e.g., getting rid of defining 'self' as a parameter). You can see PEP 3099 for an official list of stuff that will not change. But also remember that the chance to submit a PEP for Python 3.0 has past (it as the end of April), so even if your idea is not in PEP 3099, if it requires a PEP it is too late for Python 3.0. There is always Python 3.1, though.
Finally, the transition. I think the transition plan for people is pretty damn good considering how much is changing. Regardless, the Python 2.x branch will exist for several years (I suspect Python 2.7 will be the last full version release but live as a bugfix release for longer than normal). But some people worry about the chicken-and-the-egg problem of big frameworks not switching and thus no one switching over to Py3K.
Yes, some people will never switch. That's fine, enjoy Python 2.x. But others will and continue to develop on Python 3.0 while leaving their 2.x code in the past. Plus stuff will start to be developed only on Python 3.0 that will act as "bait" to get people to switch. And you can probably get away with not going to Python 2.6-only conversion of your code. As long as you can run against Python 2.6 you should be able to convert your code; Python 2.6 is a target, not the base version to be compatible with.
In the end it all doesn't matter. Python 2.x is not going anywhere, so even if Py3K turns out to be a flop Python will live on. But if Py3K does do well (and I expect it will in the end), Python will be better for it. I know that I will end up developing for Py3K exclusively whenever I can and be happier for it. Hopefully most of you will end up being happier as well.
