Python 3.2 Released 164
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."
Is the GIL removed from the interpreter (Score:3, Informative)
Is the GIL [mirocommunity.org] removed from the interpreter ?
Re:Another great Python 3.x series release (Score:4, Informative)
You don't even have to click through to the article...you can find this right in the summary:
"This also marks the first release in the 3000-series that is no longer backported to the 2.0-series."
Python 3.x has grown up and moved out of the house, so to speak. As the language develops, 2.x will be left behind and all your favorite packages will be ported to the new language using one of the excellent automated conversion "helpers" such as 2to3. Twisted, Django, PIL, etc will eventually concentrate on 3.x, and the community will be healthier overall, having been able to shed the stuff that didn't quite make sense with Python.
So stop complaining, sheesh!
-d
Re:Anti-Gravity (Score:4, Informative)
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.
Re:Is the GIL removed from the interpreter (Score:4, Informative)
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 [python.org] or something.
Re:Unnecessary complexity (Score:5, Informative)
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.
Re:What the fuck are you talking about? (Score:4, Informative)
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 [sourceforge.net] 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.
Re:Unnecessary complexity (Score:2, Informative)
I don't understand how this Py3k praising always gets such good moderation on /.
Well, that's because you just don't understand. Period.
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.
That's a mouth full but only shows you not only don't understand, but haven't bothered to even look. In what way are things more complex? You mean by adding more language features with easier syntax (example, comprehensions), things are harder? You mean by creating more explicit and less confusing exception handling, things are harder? You mean by adding additional features to support threading concurrently things are harder? You mean by improving threading concurrency, things are harder? You mean by cleaning up, simplifying, and making consistent name spaces and packages, things are harder?
Its pretty clear you're trolling and not made any effort whatsoever to actually learn whats in the 3.x series, let alone the 3.2 release.
Re:Goodbye, Python 2 - NOT (Score:4, Informative)
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
Re:Another great Python 3.x series release (Score:4, Informative)
Guido has stated quite publically that anyone is welcome to fork any version of Python - this exact topic has been discussed many times on python-dev (the mailing list for development of Python). Of course, it's up to them to maintain and popularise the fork.
What they don't get to do is call it Python. "Python" is a trademark of the Python Software Foundation [python.org] when the term is used to refer to a programming language.
The fork could be called a "Python-like" language, or even claim to be "Python-compatible"*.
* for some level of "compatible".