Python 2 to 3 conversion - embrace the pain

[Paul Rubin]

Steven D'Aprano <steve+comp.lang.python at pearwood.info> writes:
>> better to make a fork of the language
> You mean like Python 3?

No I mean like C to C++, or Lisp to Clojure, etc.  Or if you prefer, C
to OpenCL or maybe even C++ to Java or C to Go.  If you're going to
break old code, go big or go home ;-).

> There are still people using Python 1.5, some in production,

Yes, and Python 2 added stuff to Python 1.5 but it didn't break 1.5
programs (much), except for the ill-advised division change.  Which by
the way didn't introduce "true division"--rather, it replaced something
mathematically meaningful with the weird computer vagary of floating
point values.  True division would have meant exact rationals, something
that a really breaking change could have implemented.

>> C code then and now used implementation-dependent hacks ...
> People who really take backwards compatibility seriously make even their
> undocumented behaviour backwards compatible, 

The more important such hacks are still supported by compilers, though
sometimes you have to supply a command line option at compile time
to keep the hack working.

> the += operator was originally spelled =+ copying Ken Thompson's
> earlier language "B". That was changed in 1976.

That was before C was claiming to be mature and stable, so no prob.

> Post-standardisation, here are a few other backwards incompatibilities:

Hmm, maybe I'm behind the times.

> - C99 introduced variable-length arrays, but C11 relegated it to an
> optional feature which compilers are not required to support;

You mean https://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html ?
They standardized that and then un-standardized it?  Wow, that's
interesting and probably not so wise.

> - C99 changed the behaviour of floating point operations;

They weren't very well-defined before and I bet compilers supply
compatibility flags.

> - C11 finally removed `gets`.

I bet compiler libraries will keep supplying it forever though ;)

> But the biggest problem is that C compilers vary (sometimes greatly) in what
> subsets of the language they actually support. What works in compiler A may
> not even compile on compiler B, let alone behave the same.

Same as with CPython/Jython/IronPython/PyPy/MicroPython/Berp/???

>> I don't notice anyone wanting Python to change faster, in the sense of
>> breaking existing code more often. 
> Are you on the python-ideas list?

No, what's it like?  How often does anyone make a serious proposal for
more frequently breaking stuff?  How often do they want to do it?  

> after almost a decade of development, the Python 3 ecosystem is now in
> a fit state that people should prefer it for new projects. 

Given that Python 3 is a just few small tweaks added to Python 2, does
the "almost a decade of development" show that something went badly
wrong?  Would uptake had been better if it either 
  a) broke less stuff (maintaining more compatibility)
  b) broke more stuff (bringing greater benefits to switching)?

I think it's plausible that the answer is yes to both.

Also, ignoring whether people "should" prefer it for new projects: is
there info available about whether they actually do?  Someone named a
shop that deals with a lot of internationalization and benefited from
the unicode fixes, which is cool.  

I haven't been involved in any new python "projects" (meaning something
with more planning and lifecycle expectations than it takes to write yet
another throwaway script) in a while.  If management called me in about
a new project and asked whether to use Python 3, I'd have to consider it
a complicated decision, especially if the target platform wasn't one of
the widely supported ones: I did a fair amount of Python 2 on a custom
embedded hardware box and would have to experiment to find out if Python
3 even runs on that thing.  And if the idea is to break with the warty
cruft of Python 2, I'd have to consider further-out alternatives like Go
or Erlang, etc.

> Anyone remember the big backwards incompatible changes made to Visual
> Basic?  How long did that take to settle down afterwards?

No idea from me, I never used VB.