Now that Django 1.4 has dropped support for 2.4, compatibility with 3.2 is going to be a lot easier. There is an experimental branch that Vinay Sajip has created https://bitbucket.org/vinay.sajip/django/ which I believe is being considered for merging in time for Django 1.5.
> I think the minute Django supports Python 3, we'll see the level of whining drop to almost zero.
As the grandparent's author for perspective: I don't use, nor have never used, nor intend to use Django. My issues with Python 3 have no basis in Django's compatibility.
This association is a lot stronger than any of the others that you listed. C & Unix were created in tandem and were designed for each other in very many ways. For the first 10 years of C's life it was rarely used outside of Unix. But for the next 20 years or so it became the dominant language for pretty much any large project. It's only been the last 10 years or so where C has lost its domination.
Association with a very popular project has its downsides, but the upsides are much stronger, in my opinion. For instance, would Ruby be as widely known, deployed and used for non-Rails projects if it wasn't for Rails? It probably would just be another "niche" language rarely used outside of Japan. OTOH gem probably wouldn't be as badly broken as it is.
I don't think Python community ~ Django community; I do believe the loudest elements in any geek community are, invariably, web developers, who (unsurprisingly) are over-represented on the web. Once you satisfy them, the level of noise on any given subject drops considerably.
At the moment, they are pissed off that Django is not moving as fast as the language, so they whine that "nobody is moving to Python 3". As soon as that's fixed, the noise will drop.
Same for the numpy/scipy community, which is the other big one for Python. Lots of academic people there, who have a lot of spare time to bitch on the web.
I think the point is that you don't have to keep two parallel versions of the same code, since it's possible to write a single version that it's both compatible with 2.7 and 3.X.
Exactly. A fair bit of python 3 has been backported to python 2, and there exist tools (like http://packages.python.org/six/) to help paper of the cracks. You might not necessarily be able to keep things 100% source compatible, but if you think and plan a little bit you should end up with a codebase that can quickly port over to python3 once all your third party libraries are supported and stable
I don't see any reason why I must do all this extra stuff
You don't have to do all this extra stuff. You could say I'm going with python3 and simply live without (or port or re-implement) any features from third party libraries that don't have a python2 version. Or you could say I'm going with python2 and live with the facts that the language won't be evolving any more and a few years from now most libraries will only see updates to their python3 branch. Both of those approach are also perfectly reasonable depending on the scope of the project.
When there are better alternatives available elsewhere.
Obviously if there are significantly better answers than python to the problem you're facing then you should be using one of those alternatives. I was assuming that you'd already decided that python was the best fit for an upcoming project and needed a plan on how to proceed.
In addition, if you're developing a web-based system you can write your code in preparation for Python 3. When you're ready to move over, you do a one-time port and drop Python 2.x support altogether.
Obviously this depends on a few things - deployment, time/cost etc.
Should they work with 2.x which is going to go away, or 3 whose ecosystem is not ready yet.