3 ms·

Question is: could they have fixed these problems without breaking everything else?

• webmaven 11y ago
  TL/DR: No. Many, many of the changes are backward incompatible with the existing Python 2 syntax and APIs. Any changes that could be made in some compatible way have largely been backported to the Python 2.x versions (the latest stable version of which is Python 2.7.10) that have been released more-or-less in parallel with the 3.x line (search for 'backport'): https://hg.python.org/cpython/raw-file/15c95b7d81dc/Misc/NEWS https://hg.python.org/cpython/raw-file/15c95b7d81dc/Misc/NEW... Enough such has been done that you can write Python code that runs in recent versions of both Python 2 and Python 3 (which is very important for 3rd-party library maintainers that want/need to support both it in a single codebase), but to do that you will be forgoing most of the productivity and 'niceness' benefits of the sort that are described in the OP.
• collinmanderson 11y ago
  I think 3.x could have kept easily kept backwards compatibility aliases for unicode(), long(), xrange(), iterkeys(), itervalues(), iteritems(). It seems to me keeping those would have certainly have been a huge help when upgrading. Basically, I think a lot of the shims in the six library could have been included in 2.6, 2.7 and 3.x. Also, I think it would have been wise to spread the breaking changes over many releases, not saving them all for one massive breakage. That way you can deal with only a few subtle bugs and breakages at a time.