[wladimir]

I am certainly not denying that there are issues or saying that his issues don't need to be addressed.

However I'm a big proponent of 'breaking with the past' once in a while, to fix issues that have snuck into the language/library/system, and to clean up the cruft. Yes it will bring some frustrating porting, but the end result will be a cleaner more focused language.

[mcdonc]

Your original post (and to an extent your reply above) was a bit dismissive, I think. Dismissiveness is not really a unique sentiment here; I see a lot of posts along the lines of "well yes he's complaining but it's a break with the past and its for the better, it's just a matter of time, and it will all work out in the end, yada yada"..

My point is that for this to actually be true (as opposed to just being wishful thinking, which there's a lot of right now), people are going to have to not only port their libraries but they will also need to maintain the resulting code. If the library is at all popular already, the resulting code will, for some open-ended period of time (perhaps "forever") need to work on both Python 2 and Python 3. And right now, though producing a port isn't monstrously hard, maintaining the resulting code across the 2/3 straddle is just no fun. The code looks bad, it's harder to read, it's harder to maintain, it's just less fun overall. Basically, maintaining a Python 3 port just takes some of the fun and aesthetic out of maintaining an open source library. It's an imposition to those folks who want their code to be popular, forward-compatible, and beautiful due to the need to straddle.

IMO, I'm not sure that a Python 2.8 helps much here, but a more backwards compatible Python 3.3 would. For example: match py3 bytes behavior with py2 string behavior, add u'' literals back in, maybe readd iteritems/iterkeys/itervalues on dict as aliases so we can use a common API for dicts, add the print keyword back in maybe, and other minor things that are really easy to do and don't have much defensibility other than "it's cleaner to not have to have bw compat here".

[wladimir]

Yes, a backward compatibility mode that could re-add those things would be nice (which could be enabled by adding a pragma "from __past__ import old_unicode_literals", for example). It would allow for a more gradual transition.

[mcdonc]

The pragma wouldn't really work. It'd have to work in all old versions of Python to make any sense, and it doesn't. For unicode literals in particular, it should just be true in Python 3.3+ that u'' = '' out of the box.

[cdavid]

Breaking stuff is worthwhile if it brings other things in exchange. Cleaner is almost never a good enough reason in my experience. New features is what makes people willing to upgrade. People will evaluate whether porting is worth the pain over this feature vs effort line. Armin is not the only one who wonders whether it really is worths it.

[wladimir]

But as more and more new features are being added to 3.x and not to 2.x (and assuming 3.x won't break compatibility with itself), won't there automatically be a point in which the features are worth the pain?

Even if not, the python devs are not trying to define this point for anyone, you can stay with 2.7 the rest of your life if you want to. I don't think a "2.x will no longer be maintained even for bugfixes" date has been established.

[cdavid]

There may be a point at which the features may worth it, I don't see why it should be automatic.

Python 2.x is not going away, but staying at 2.7 is not a long term solution either.