Python 2 to 3 conversion - embrace the pain

[Paul Rubin]

Steven D'Aprano <steve+comp.lang.python at pearwood.info> writes:
> It may, or may not, turn out that in hindsight there might have been better 
> ways to manage the Python2-3 transaction. Let's be honest, a lot of the 
> changes could have been introduced incrementally...

Why did the changes have to be introduced at all?

> I suspect that without the discipline and bloody-mindedness to just say NO 
> to requests to delay removal, Python would follow all those other languages 
> that have an ever-increasing pile of cruft that can never be removed because 
> it will break somebody's code. Design mistakes, obsolete features, 
> misspellings, "it's like that for historical reasons", and other nasties.

The idea of "maturity" (an advertised feature of Python 2 back in the
day) is that the pile of features is no longer growing so fast.  Right
now I'm messing with some C code written in the 1980s and it still works
fine.  I have a hard time imagining using Python 3 for anything.  Python
2 has its cruft but it's familiar and comfortable, and Python 3 gets
minimal benefit for most of the breakage that it did (possible exception
of the Unicode changes).  It still has most of the same mistakes and
warts.  If I wanted to get away from those, I'd use Go or Ocaml or
Erlang or Haskell or Javascript (possibly through a compiler like
Purescript) or whatever.

I'll see if I can remember what it was but I found some annoying
incompatibility just a week or so ago that I don't think 2to3 would have
caught, making me scared of Python 3 all over again.  I still think
CPython should have stayed with Python 2 forever, and Python 3 should
have been PyPy-based, letting PyPy drive its design, so that it could
have introduced bigger changes with bigger benefits.  As we're seeing,
even small incompatibilities and breakage cause big resistance, so if
you're going to break stuff at all, you might as well go big.  Most old
programs will never be ported either way.