The blogosphere is rapidly heating up with dismay and sometimes outright anger at the bungling of the Python 3000 release. I walked into the #django IRC channel and I got my head bitten off for asking which version of python I should use for django. (After the channel cooled down some, I was able to ask why: Evidently every 5 minutes someone asks if django is py3k compatible).
Herein lies at least some vindication for Sun’s ‘backwards compatibility trumps everything’ mode of thought regarding java releases. You must be backwards compatible.
What intrigues me some is that this python3k release could have been done so much nicer, and it wouldn’t have been too difficult:
Start with a ‘version’ indicator in the source. Something like ‘python 3′ right at the top of the file (it would be legal nowhere else, to avoid having to declare a real new keyword). This then gives the interpreter the opportunity to parse the file differently, depending on version. Lack of version indicator means its assumed to be python 2.6 (the last pre-3 release).
Now, some py3k changes may not be easily solvable even if the interpreter knows what the code was written for. But the simple stuff, such as py3k ‘range’ being the same as py2k’s ‘xrange’, and py3k no longer having an xrange function at all, could easily be handled by a backwards compatible py3k interpreter. With some effort I bet you could build a py3k that is 100% backwards compatible in this fashion. Python is a dynamic language with duck typing, which makes this proposal quite a bit easier compared to a language that uses nominal typing, such as java. So why hasn’t python taken this option?
I have no idea.
That’s not all she wrote though: I am still waiting for a language that offers infinite smooth upgrade ability for its own language, its own core libraries, and for any third party library that chooses to offer it. I’ve tried to work this out and its not exactly simple to build such a programming language, but it can be done: Each library that wants to offer backwards compatibility can break its API and offer adapters that essentially build a ‘view’ that acts like the older API. This way code expecting the old API can work with code that expected the newer API without breaking it. A few languages / loaders offer the ability to load whatever version a program expected, but those tools simply don’t work if one module of a program expects v2, and the other expects v3. That’s why you need views, so that the actual library itself can always be at the latest version. Also should be great for security updates: You now never need to update multiple versions. Just update the latest version and make sure the adapters work well.