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

Comments

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