[Python-Dev] Another update for PEP 394 -- The "python" Command on Unix-Like Systems

[Neil Schemenauer]

On 2019-02-13, Terry Reedy wrote:
> It appears python is already python3 for a large majority of human users (as
> opposed to machines).

IMHO, the question about where /usr/bin/python points is more
important for machines than for humans.  Think about changing
/bin/sh to some different version of the Borne Shell that changes
'echo'.  Or changing 'awk' to some incompatible version.  That's
going to break a lot of scripts (cron jobs, etc).

I experienced the bad old days when you couldn't rely on /bin/sh to
be a proper POSIX shell.  It was a mess and it wasted countless
hours of human life to work around all the flavours.  Python is not
as fundamental as the Unix shell but it has replaced a lot of shell
scripting.

How can we avoid making a lot of work for people?  I don't see an
easy answer.  We don't want Python to become frozen forever (whether
it is called 'python', 'python3', or 'py').  OTOH, making
/usr/bin/python point to the most recent X.Y release doesn't seem
like a good solution either.  For example, if I used 'async' as a
variable in some of my scripts and then 3.7 broke them.

Should we dust off PEP 407 "New release cycle and introducing
long-term support versions"?  Having /usr/bin/python point to a LTS
release seems better to me.  I don't know if the core developers are
willing to support PEP 407 though.  Maybe OS packagers like Red Hat
and Debian will already do something like LTS releases and core
developers don't need to.  /usr/bin/python in Red Hat has behaved
like that, as far as I know.

Another idea is that we could adopt something like the Rust
"language edition" system.  Obviously lots of details to be worked
out.  If we had that, the 'py' command could take an argument to
specify the Python edition.  OTOH, perhaps deprecation warnings and
__future__ achieves most of the same benefits.  Maintaining
different editions sounds like a lot of work.  More work than doing
LTS releases.

Maybe the solution is just that we become a lot more careful about
making incompatible changes.  To me, that would seem to reduce the
rate that Python is improving.  However, a less evolved but more
stable Python could actually have a higher value to society.

We could create an experimental branch of Python, e.g. python-ng.
Then, all the crazy new ideas go in there.  Only after they are
stable would we merge them into the stable version of Python.  I'm
not sure how well that works in practice though.  That's similar to
what Linux did with the even/odd version numbering.  It turned into
a mess because the experimental (next) version quickly outran the
stable version and merging fixes between them was difficult.  They
abandoned that and now use something like PEP 407 for LTS releases.

Regards,

  Neil