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."

Another great Python 3.x series release

[Anonymous Coward]

That no one will use because there is no compelling reason to port all that cool stuff developed for the 2.x series.

Re:Another great Python 3.x series release

[Anrego]

This is my biggest complaint with python (I have others, I'll admit I have little love for python). This is not the way to develop a language.

I'll admit I've never developed a programming language, but I have worked on large, long term libraries, and I think the same principle applies. All those stupid design decisions and approaches that are now obsolete and make no sense.. you have to make them still work anyway. You can spew lots of warnings.. but to me breaking backwards compatibility in a _programming language_ is sloppy and completely unacceptable.

Re:Another great Python 3.x series release

[bjourne]

That's exactly what Python did and does, where appropriate. Where it isn't, such as the changed meaning of string literals (they are all unicode now) or the division operator, the breakage is hard. There is no way around that if you want to modernize the language. C# did it too, Java did not. Which is why generics in Java are half-assed and why there are a lot of quirks in the language that traces their roots back to version 1.1 or earlier.

Re:Another great Python 3.x series release

[luis_a_espinal]

This is my biggest complaint with python (I have others, I'll admit I have little love for python). This is not the way to develop a language.

I'll admit I've never developed a programming language, but I have worked on large, long term libraries, and I think the same principle applies. All those stupid design decisions and approaches that are now obsolete and make no sense.. you have to make them still work anyway. You can spew lots of warnings.. but to me breaking backwards compatibility in a _programming language_ is sloppy and completely unacceptable.

Well, you don't have to migrate to Python 3.x. There are a lot of Java 1.2 code out there that will never be migrated, code that sooner or later will not run as intended with new JVMs and JDKs. Code written in COBOL still runs and will never be re-writen (not in our lifetimes).

If it works for you on the 2.x series, most likely it will work fine in years to come. Coming from a Java world, I can tell you I wish the JCP had done the same with many Java crap. Hashtables and vectors should have been deprecated long ago; the '+=' operator in Strings should also have been deprecated; we should have created a damned new collections library so that we could have true generics without type erasure; the JVM should have implemented support for tail recursion; and we should have gotten rid of this one-class-def-per-class-file non-sense.

True, it would have broken a lot of stuff, but only for those that want/need to migrate - many do not. But it would have been a way to get things right and undo a lot of past design wrongs. At some point, it is time to cut backwards compatibility. For those who can't go to the 3.x series, they should simply stay with the 2.x series and work as usual.

Re:Another great Python 3.x series release

[dkleinsc]

Counterargument A: The stupid design decisions and approaches that are now obsolete and make no sense should be forced out of code. Otherwise, the Bad and Wrong version persists a lot longer than it should: some mediocre developer will Google how to solve a Python problem, get something that explains the Bad and Wrong version, puts it into their code, may get a bunch of deprecation warnings, but figures "hey it works, good enough". And if you need an example of how badly out of hand that can get, look at PHP, which still has to support really really stupid things from PHP2 or so because of backwards-compatability, and thus leaving behind a legacy of horrific PHP code.

Counterargument B: Ensuring backwards-compatibility always forever and ever ensures that the language complexity can only grow, never shrink. And thus you grow and grow and grow until eventually the language cannot even be completely defined using BNF or anything similar. Case in point: C++.

Re:Goodbye, Python 2 - NOT

[Animats]

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:

• BeautifulSoup (HTML/XML parser - replaced by HTML5parser, which is much bigger and slower and has a completely different output tree.)
• MySQLdb (MySQL database interface. The developer says it's too hard to convert it to Python 3.)
• M2Crypto (interface to OpenSSL - replaced by new, incompatible SSL module.)
• SGMLparser (Used by some other modules)
• FeedParser (Reads RSS feeds. No replacement.)

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 [google.com] 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.

Re:Confusingly similar name

[PCM2]

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.