[yoz-y]

Obsolete was a wrong word to use, I admit that. But from an integrator's perspective supporting both versions is a mess. The problem is that the interpreter has the same name (python), the libraries export the same symbols (well, same names, different signatures for extra fun) etc.

Like you said, Python team sees the 3.x series as the successor AND as a replacement for Python 2.x. They were never meant to exist one beside the other (or, there was no thought put into this before the release).

From my perspective, giving people the choice between 2 or 3 will only give us problems down the road, which is why I vehemently discourage it.

[jprzybyl]

And yet a transition period is needed.

I wonder what about this made this difficult. Was it because it's a language interpreter? Libraries have this problem sometimes, but not as much. (I never hear of issues with gstreamer between 0.10 and 1.0, for example.) Maybe it was just that a binary called python existed? Maybe we should have just said "screw it, python means python2, end of story."

Don't know. What would you have preferred?

[yoz-y]

Well, in my ideal world maintainers would have put all possible effort to porting libraries to python 3 and put python 2 versions into legacy mode (e.g.: security updates, fork it if you want to continue on the 2-branch).

In my field what seemed to keep people on python 2 for a long time was numpy or scipy (or both, I do not remember which) which did not get a 3 upgrade for a long time.

Either that, or just call it something different, kind of like perl6. There is no perl6 distribution shipping a perl library or some perl.dll that clashes with perl5.