Trying to avoid sounding like a fan-boy but your python bashing goes a bit far, imho.
CPython itself is stable and well documented, but it's frequently breaking backwards compatibility across versions.
I think you are over-dramatizing this. The big transition to Python 3.0 is still ahead of us. I'm using python since 2.3 and the path to 2.6 has been much less troublesome here than CPAN or the jar interdependency hell have ever been.
I especially find your claim that Perl is "stable and reliable as hell" amusing. CPAN has always been hit & miss for me and I've seen much greater variance in the quality of 3rd party perl modules than in python land.
If I scpy a Django directory to a different server I'm __surprised__ if it just works. Doesn't that say enough?
I think that says more about your deployment methods than about python or django.
Any Python library written today won't run on the computers of tomorrow. That's a pretty big price to pay for a print() function.
That's simply not true. Nobody stops you from running python 2.4 or older on computers of tomorrow. Just like you don't upgrade JVM versions willy-nilly in production.
Python has it's quirks and problems like any other platform. But the particular issue you're going at here (backwards compatibility) is really far from our biggest concern.
Actually, I like Python. I think it has a lot going for it and I use it on a daily basis.
You say that you shouldn't upgrade Python or the JVM willy-nilly. I say: why not? Why do you find it acceptable that languages break existing functionality?
It's not actually about breaking functionality. Both java and python go through a long deprecation period before removing language features. Most Python 2.4 code will run on 2.6 just fine, a few warnings nonwithstanding. Just like most Jdk1.3 code will run on 1.6, again with a bunch of deprecation warnings.
The bigger problem with willy-nilly upgrades is that the new version is not the version you tested on. It might introduce new bugs, unwillingly. I have seen many more subtile problems with minor version jdk updates (e.g. changes in GC behaviour or outright segfaults) than with any python upgrade so far.
The gist is that when you upgrade your environment then you'll just naturally also update the codebase to match it anyways. Or do you upgrade your jdk1.3 project to jdk1.6 and then just ignore the 20 screens of warnings scrolling down on each build?
You don't. You either just stick with what works (for finished projects) or port it forward (for ongoing projects).
CPython itself is stable and well documented, but it's frequently breaking backwards compatibility across versions.
I think you are over-dramatizing this. The big transition to Python 3.0 is still ahead of us. I'm using python since 2.3 and the path to 2.6 has been much less troublesome here than CPAN or the jar interdependency hell have ever been.
I especially find your claim that Perl is "stable and reliable as hell" amusing. CPAN has always been hit & miss for me and I've seen much greater variance in the quality of 3rd party perl modules than in python land.
If I scpy a Django directory to a different server I'm __surprised__ if it just works. Doesn't that say enough?
I think that says more about your deployment methods than about python or django.
Any Python library written today won't run on the computers of tomorrow. That's a pretty big price to pay for a print() function.
That's simply not true. Nobody stops you from running python 2.4 or older on computers of tomorrow. Just like you don't upgrade JVM versions willy-nilly in production.
Python has it's quirks and problems like any other platform. But the particular issue you're going at here (backwards compatibility) is really far from our biggest concern.