On python-3000 there has been a flare-up of people worrying about porting their apps over to Python 3.0. At this point it is looking like Neal Norwitz's C implementation of the 'warnings' module will be combined with a special Py3K warning for when your code does something that differs between 2.6 and 3.0. It will have minimal cost and will be off by default. Combine that with the 2to3 refactoring tool and it should help ease the pain of moving code from 2.x to 3.x.
What has people worried, though, is release schedules. Python 3.0a1 should hopefully be out June or July of this year and with 3.0 final sometime in 2008. Python 2.6, if you follow typical 12-18 month delays between minor releases, should be out sometime in 2007. That puts the amount of time between 2.6 and 3.0 at less than a year. This has people worried.
People want their code to move over to 3.0 easily, which I understand. People with large codebases would probably be happy if we just incrementally changed the 2.x branch so that it just morphed into 3.0 in the future at some point. But the problem with that is it would delay reaching what has been planned for 3.0 by years. We cannot break more than one piece of syntax between minor versions without causing major transition headaches for people. And Guido doesn't want to wait years (and frankly neither do I).
This is why the decision was made to just go all-out and break all of the mistakes made over the years at once. It's like ripping off a bandage; you can either do it very slowly or just pull hard and get it over with. Unfortunately the people with the large chunks of code are saying that pulling hard is just too painful and would still take too long because of the amount of change.
And this is why people are worrying that 2.6 will not help transition well enough or fast enough before 3.0 comes out. That supposedly means that third-party libraries will not be available for 3.0 and thus nothing of value will be written in it, essentially making 3.0 still-born.
And this is where I disagree. It will take YEARS before people start coding in Py3K by default, let alone transitioning over in droves. 3.0 is most likely going to be an early-adopters release for those people who do not need to rely on third-party libraries. It will also be there to work out any issues that come up from the community. Guido has already stated that 3.1 will be based on feedback from 3.0 and he really doesn't expect people to really take until 3.2.
People who want to play with 3.0 will slowly transition there stuff over and then the third-party support will grow. And while all of this is happening the 2.x series will continue to gain features from the 3.x series to make transitioning easier until people just start to code in teh Py3K style naturally. And obviously people who write stuff from scratch that is not dependent on anything but the stdlib will continue to crop up.
In other words, I don't expect everyone to transition in a flash to Python 3.0 from 2.6. I expect it to be very slow. It might take several versions of Python before there is a bastardized 2.x release that has everything that 3.x has as well (or close to it) so that code can run in both versions of Python. This is not a race. It will be some time before various OSs ship with 3.x anyway, so there is no huge rush.
What could happen is apps fork at Python 2.5. They keep that version as their very backwards-compatible version and update for security reasons and such. With new features they can target 2.6 and up, helping them transition to 3.x at some point in the future. This might take some time, but whatever; 2.x will be maintained for quite a while.
But honestly, in the end, I don't really care if Py3K is never as popular as Python 2.x. As long as Py3K is still fun to develop I will continue to work on it.
