THE FORCED BACKWARD INCOMPATIBILITY

Do you see FIOC 3000 ever taking off as the de-facto FIOC standard, or we'll have around 2.x forever? I know that there's code that won't be updated, it's a shame having to maintain the older branch for ages to come. Shame on you, Guido.

It also worries me that not much stuff is getting updated at all, and even now stuff popping out right now is written for 2.x.

>>20
It's not a fork, it's a branch. They already have a maintainance branch for each released version anyway.

2.7 got a lot of the new features, they can be enabled with the import statement. Changes who should to go to all active versions are done to the trunk and then merged (This gets easier with the migration to a DVCS.) There'll often be a few necessary changes, but it's not like it's a complete rewrite, a lot of patches will apply just fine to both.

There's currently no plans to have /usr/bin/python go to python3, so it shouldn't be a problem for a distribution to ship both at the same time.

If you're maintaining an old project, or starting a new one that needs a library that isn't available for python 3 yet, it's perfectly fine to continue to use 2.x.
If you are doing something new without many dependencies, or are using Python in a teaching environment (Hi, Hal!), please consider taking advantage of Python 3.x's cleaner syntax and standard library API, that avoids some surprises caused by unfortunate decisions that came about during the evolution of the Python language.

If you are the author of a Python library that needs to be compatible with 2.x., it is recommended that you keep it in 2.x, but do the necessary changes to get a good conversion with the automatic 2to3 code converter. This should let you to do releases for both versions while keeping a single code base.