Slashdot Mirror
Python 3.2 Released
digitalderbs writes "Python 3.2 was released on Feb 20th 2011 with many new improvements. New features include many useful updates to the unittest module, a stable ABI for extensions, pyc repository directories, improvements to the email and ssl modules and many others. This also marks the first release in the 3000-series that is no longer backported to the 2.0-series."
That no one will use because there is no compelling reason to port all that cool stuff developed for the 2.x series.
Come on, guys. How does this help us keep up to date on political events, popular music, or funny videos?
Is the GIL removed from the interpreter ?
Jehovah be praised, Oracle was not selected
I don't know of a major Python library that isn't upgrading to Py3 - and this release marks the tipping point where we wave goodbye to the aging 2.x codebase.
PEP-3003, the moratorium to changes to the language to allow alternative Python implementations to catch up, only applies up to the 3.2 series so we're going to continue moving forward from here. Nobody's forcing Python 2 users to upgrade their code, but there's many advantages and ever decreases hurdles to doing so.
Don't fear change, this change is good and necessary for the advancement of the language.
Have they added Anti-Gravity yet?
Summation 2
I don't understand how this Py3k praising always gets such good moderation on /.
Python 3 has left the original focus of the language as something simple and easy to use. All the changes are towards a MORE COMPLEX language, I see no change that makes it simpler to use, no change that requires less code than the former version.
Py3k is moving in the direction of Java, where nothing can be done without typing a hundred lines of code. An example from the Python documentation:
17.1.3.1. Replacing /bin/sh shell backquote
output=`mycmd myarg`
==>
output = Popen(["mycmd", "myarg"], stdout=PIPE).communicate()[0]
I cannot see how would anyone call this an "improvement"... Oh, sure, it gives me more options, more control, but if I had wanted to finely tune the innards of the program I would have used C++.
brings a different context to the the phrase "blow jobs"
(1.21 gigawatts) / (88 miles per hour) = 30 757 874 newtons
I extensively use Numpy at work, and that was the primary reason Python 3 was useless to me. However, I should mention that as of Numpy 1.5 release some months ago, Python 3 is now supported. The FAQ page on the Numpy website just hasn't been updated properly.
And Scipy 0.9.0 *does* support Python 3.1. It's currently at release candidate 5, i.e. within a few weeks of an official release. See the release notes from yesterday.
PyLab, I'm not certain about. Matplotlib has an initial port but I think it's not really working yet.
I think now that Numpy and Scipy are running on Python 3.x you'll see a lot more interest in people running it who do real stuff with Python.
PIL is working on Python 3; "The current free version is PIL 1.1.7. This release supports Python 1.5.2 and newer, including 2.5 and 2.6. A version for 3.X will be released later" (source). So is Django, Turbogears, wxpython, pygtk, etc. You can vote on which major 3rd party packages you'd like to see ported.
PyQT, CherryPy, Genshi, and many others are already ported to Python 3.
But... but... I just bought a special unicode keyboard just so I could write code that could never be posted on slashdot!
If I have been able to see further than others, it is because I bought a pair of binoculars.
I don't know of a major Python library that isn't upgrading to Py3 - and this release marks the tipping point where we wave goodbye to the aging 2.x codebase.
Ah, denial. Some major modules that aren't making the transition:
And those are just ones I happen to have used.
Because the Python community is so tiny, there are major modules that are maintained by only one person. In many cases, they've moved on to other things, and no one is maintaining the modules. The major changes required to move to Python 3.x are non-trivial and aren't being done, because someone would have to take responsibility for a big module they didn't write to do the conversion. In some cases, there are newer, completely different modules with different APIs that perform the old functions. So end users have to do a major rewrite on production programs just to stay in the same place. It's a huge transition. Guido has this smoke-and-mirrors pitch claiming that it's "done". That's because the Python organization, such as it is, disclaims all responsibility for getting modules ported. So it's not his problem that it sucks.
None of the non-CPython implementations are making the transition. Not IronPython (abandoned by Microsoft). Not Shed Skin (only one developer). Not PyPy (defunded by the European Union). Not even Google's own Unladen Swallow is moving to Python 2.6, (Google seems to have abandoned Unladen Swallow after discovering that Guido's insistence on excessively dynamic features meant a JIT compiler didn't speed it up much.) The transition to Python 3 has thus killed all other Python projects.
CPython is a naive interpreter, roughly 60x slower than C. It's been stuck at that speed for a decade. And now, that's all we have left.
If you're using Python for anything important, start working on your exit strategy.
There's a little bit of revisionist history going on in your post but I don't get the impression that's by intent.
Ah, denial. Some major modules that aren't making the transition:
That was a silly thing for him to say. Clearly some modules are not actively being ported. That, however, doesn't mean they won't or can't.
The major changes required to move to Python 3.x are non-trivial and aren't being done
Very much over stating the difficulty. There has already been a number of porting sprints. In a number of cases, rather large frameworks have been ported over a weekend. By in large, the porting effort actually is extremely trivial and frequently, the automated tools can complete 90-95% of the port by themselves. Really, the ports which tend to be problematic are the ones with large, legacy code bases. These are non-trivial not because of their size, but because of the porting effort in of themselves is a function of line count.
In some cases, there are newer, completely different modules with different APIs that perform the old functions. So end users have to do a major rewrite on production programs just to stay in the same place.
Could you be more specific. I'm actually drawing a blank here. Its true some functions/classes have been moved to other packages. Most of the time its as simple as changing an import or a namespace prefix associated with a function call. Again, most of the tedium is addressed by means of the automated porting tools. And if you do have examples, please offer up why such an example affects such a wide breath of existing code its more than a corner case.
It's a huge transition.
Again, you're way overstating the problem.
Guido has this smoke-and-mirrors pitch claiming that it's "done". That's because the Python organization, such as it is, disclaims all responsibility for getting modules ported. So it's not his problem that it sucks.
Trollish and red herring in nature. Not really applicable to the discussion at hand. So now Guido is responsible for all python code which has ever been written. Such a statement is silliness at best.
None of the non-CPython implementations are making the transition.
This has what to do with anything? And how many dozens of people really care?
Not IronPython (abandoned by Microsoft).
So now a port of python that no one used is a significant weight preventing the adoption of the latest python release? Completely rediculas. If anything, it further underscores the stupidity of IronPython and MS' mind-share-gimick-marketing rather than serving as a detracting for python migration. Bluntly, I'm sure IronPython's three users are really upset that they made such woefully bad decisions to adopt IronPython (contrary to the rest of the world's warnings and MS' very long associated history).
Not Shed Skin (only one developer).
That's because he's one developer and doesn't have the man power. Its not that he won't, rather, its that he is simply one man. Furthermore, Shed Skin is a niche product. Its neat and all, but it has a long way to go before, frankly, anyone other than that one developer really gives a crap about it. Don't get me wrong, its a cool tool, but I won't use it for production. Hell, most python developers don't even know about it. And when they do, they tend to think of it as an experimental toy. Seemingly, the author sees it this way too. So again, not a detractor for Python 3.x in the least. You're being silly.
Not even Google's own Unladen Swallow is moving to Python 2.6, (Google seems to have abandoned Unladen Swallow after discovering that Guido's insistence on excessively dynamic features meant a JIT compiler didn't speed it up much.)
Completely wrong and extremely trollish in nature. Unladen Swal
And which has a name confusingly similar to that of Python 2. And which uses the same file name extension as Python 2. And which takes web hosting services that currently offer Python 2 far longer to adopt.
Consider yourself lucky with Python, then. C code written for two entirely different machine architectures uses a similar (but inconsistent) syntax and the same file extensions; in fact, the same *.c files might not compile successfully using two different compilers on the same box. Really, you're holding Python to a standard that no other language has ever been able to meet.
Breakfast served all day!