Not a direct answer to the question but Ruby 2.0 is expected to be backwards compatible with the current production release, 1.9.2, while just adding extra features. I'm not particularly well versed in Python 3 but I believe it wasn't intended to be backwards compatible.
For good or bad, the ruby community tends to embrace changes faster than the Python community. For example Rails is going to drop 1.8.7 support in the next release 3.2
It's hard to read that data because there's no label on the vertical axis. But through all the charts there, it looks like 1.8.7 is still the most widely deployed version. I'd imagine it'll remain that way for a while longer.
From personal experience the community at large is eager to move to Python 3. It has more to do with tremendous inertia generated by critical components being tricky to port to Python 3. Usual suspects Django and Twisted come to mind. IIRC NumPy gained support only recently.
It does not help that useful stuff from 3.x get backported to 2.x or available via __future__, and that IMHO Python 2.7 is awesome so the urge is not quite there (well, not as much as working with Ruby 1.8 when you tasted 1.9)
If you would like more resources than the FUD laden wall of shame, feel free to visit: http://getpython3.com/
The timeline for Python 3 adoption was always measured in years - not one, not two, but more. We're not a development team or group that cough up unicorns about how long adoption of a backwards incompatible version will take.
Django has a Python 3 roadmap, as does twisted, as does PyPy, Numpy, etc. The PSF and companies are now funding Python 3 ports.
In fact it's not a bad thing that 2.7 is so awesome - that makes it possible for people with large codebases to essentially put off the port to Python 3 for ever. Or maybe to skip Python 3 and port to Python 4 in another twenty years. Both are perfectly acceptable engineering decisions, and we are (or should be) talking engineering here, not religion.
As Jesse Noller has pointed out elsewhere, the transition was never intended to be instantaneous. The Wall of Shame might publicize those packages that are causing pain points, but it offers no prescriptions.
> It does not help that useful stuff from 3.x get backported to 2.x or available via __future__, and that IMHO Python 2.7 is awesome so the urge is not quite there
Part of the reason that the urge isn't quite there is because there hasn't been enough time for 3.x to diverge from 2.7, the end of the 2 line. 3.2 came out eight months after 2.7 and the feature differences aren't large, especially considering that 3.2 was developed at the same time as 2.7 so many of the newly added features are the same.
As 3.x continues on with the 3.3 release next fall, the differences will become greater, the feature sets will become different, and the urge may start rising. As was said before, this is all measured in years - we can't expect that 3.x (the interpreter and standard library, on its own merits) just suddenly jumps ahead.
Really? It seems to me like a mostly small vocal group is pushing 3. Most people I talk to actually using it heavily in production are ambivalent or actively planning on staying on 2.
Python 3 is exactly how not to do a major language change. They broke enough that porting isn't trivial, and for many programs there just isn't any benefit. Plus the performance noticeably regressed.
> Python 3 is exactly how not to do a major language change. They broke enough that porting isn't trivial, and for many programs there just isn't any benefit.
All of that would have been acceptable, if they also implemented some major language fixes and adding some cool new features. Better closure support comes to mind...
I think the best thing about Ruby is the really fierce competition between implementations, which also reflects on the developers. The Ruby community is used to ensuring compatibility between JRuby and MRI(1.8 and 1.9) for a long time now and Rubinius support is getting `en vogue`. Projects like Travis will ensure that testing on 2.0 is "just" anther field on the build matrix.
> I think the best thing about Ruby is the really fierce competition between implementations, which also reflects on the developers.
I don't see any fierce competition against implementations in Ruby. I see that in Javascript implementations (and in HTML engines), but not in Ruby.
I wish that was not the case, but for real competition to exist, and also be fierce, each implementation should push other implementations to go better, adopt its successful features, etc.
What I do see is just parallel development of different implementations.
