Let's hope it will gain more acceptance and usage than Python3. Do they intend major changes?
The Wall of Shame gives a very partial overview of the situation: http://python3wos.appspot.com/
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)
https://bitbucket.org/pitrou/t3k/wiki/Home
It's described as "an experimental, work-in-progress port of Twisted to Python 3".
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.
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...
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.
The reports of death are grossly overstated.
Already a lot of YEARS have passed, not one, not two, but more. We're even in 3.2 for heaven's sake.
> Django has a Python 3 roadmap
Yeah, has had one for years. How is that going?
> The reports of death are grossly overstated.
The reports of movement in this front are grossly overstated too.
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.
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.
Rails 4 will drop Ruby 1.8 for good.
Check out how quickly 1.9.2 has been adopted in production Rails apps: http://blog.newrelic.com/2011/09/28/state-of-the-stack-a-rub...
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.