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?
Yep, "import antigravity" is an easter egg. It also contains geohash code, but the core functionality of the module demonstrates how easy Python is;
import webbrowser
webbrowser.open("http://xkcd.com/353/")
Works with every major web browser, no muss, no fuss.
Yes, it would be great if an update to this were covered in the article, like if they put notes on changes to the GIL right here or something.
Python never had shell backquotes. The code snippet is highlighting one way that shell backquotes from other languages can be handled. (The "backquote" operator in Python 2.x is equivalent to "repr", e.g. `3+4` yields '7'; it is now gone in Py3K for obvious reasons).
In Python 2.7 and 3.1, there's now a convenience function for capturing program output:
subprocess.check_output('ls -l')
I doubt your claim that Py3K has made things more complicated. If anything, it has made things simpler: less language "burrs" (e.g. / now does float division, eliminating the need to stick float() on one argument or use weird constructs like 1./3), a cleaner standard library ("io" is a great idea), and proper Unicode/8-bit distinction.
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.
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!