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

[Gregory P. Smith]

On Thu, Feb 14, 2019 at 9:29 AM Barry Warsaw <barry at python.org> wrote:

> On Feb 13, 2019, at 23:08, Matěj Cepl <mcepl at cepl.eu> wrote:
>
> > Is this relevant to the discussion at hand? We are talking about
> > the binary /usr/bin/python3 which will be surely be provided
> > even by Python 4, won't it?
>
> Why would it be?  Since this is all hypothetical anyway <wink>, I’d more
> likely expect to only ship /usr/bin/python.
>

Because nobody can use 'python' and expect that to be anything but a 2and3
compatible interpreter for the next 5+ years given we live in a world where
people routinely have a very real need to write #! lines that works with
obsolete distributions.  python3 implies >=3.x, thus python 4, 5, 6, 2069,
3001, and 90210 should all have python3 point to them.  realistically
people will stop referring to python3 by 2069 so we could consider removing
the recommendation at that point.

2020 is not the end of use or end of importance for Python 2.  It is merely
the end of bugfixes applied by python-dev.

A thing I want to make sure we _don't_ do in the future is allow future
pythonN binaries.  python4, python90210, etc.  those should never exist.
python, python3, and pythonX.Y only.  If we were ever to go back on our
promise and create another world-breaking python version, it could get its
own canonical binary name.  But we're specifically planning _not_ to make
that mistake again.

I suspect most of my opining below will be contentious to multiple people
because I describe a state of the world that is at conflict with decisions
multiple independent distros have already made.  Accept their mistakes and
move on past it to the hack in that case:

A new "py" launcher isn't going to solve this problem - it is separate and
should be its own PEP as it has its own set of requirements and reasons to
be considered (especially on platforms with no concept of a #!).  Recommend
"py" today-ish and nobody can rely on it for at least 10+ years in a wide
support cross platform scripting type of situation because it won't be
present on the obsolete or long term supported things that people have a
need for such #!s to run on.

Not our problem?  Well, actually, it is.  Matthias speaking for Debian
suggesting they don't want to have "python" at all if it isn't a synonym
for "python2" because it'll break software is... wrong.  If software is not
3 compatible and uses "python", it'll also break when python is python3.
Just in a different manner.  "python" should point to python3 when a distro
does not require python2 for its core.  It should not _vary_ as to which of
2.7 or 3.7 it will point to within a given stable distribution (installing
python2.7 should never suddenly redirect it back to python2).  But "python"
itself should always exist when any python interpreter is core to the OS.
That means if a distro no longer requires python2 as part of its base/core
but does require python3... "python" must point to "python3".  If a posixy
OS no longer requires python at all (surely there are some by now?) the
question of what python should point to when an OS distro supplied optional
python package gets installed is likely either "nothing at all" or ">=3.x"
but should never be decided as "2.7" (which sadly may be what macOS does).

Do we already have LTS _stable_ distributions making that mistake today?
If so they've done something undesirable for the world at large and we're
already screwed if that distro release is deemed important by masses of
users: There is no way to write a *direct* #! line that works out of the
box to launch a working latest version Python interpreter across all
platforms.

The hack to make that work otherwise involves:

```sh
#!/bin/sh   # (or bash if that much is guaranteed)
... some shell logic to find _an_ acceptible interpreter ...
exec "${DISCOVERED_PYTHON}" - <<<END_OF_PYTHON_CODE
# actual Python code here, escaped as appropriate when needed for being
embedded within a shell script
END_OF_PYTHON_CODE
```

Obviously someone should write code to take a standalone single file python
program as input and generate that wrapper on it (and upload the tool to
pip) instead of telling people to reinvent their own or cut and paste it
into their direct source files.

This problem isn't new.  A chapeau rouge distro shipped python -> 1.5.2 for
eons at the same time as shipping 2.x on the system.  The entire world
wanted to be writing 2.0-2.4 code but there was no simple "python2" binary
on most systems with 2.x installed yet.  We all survived despite ourselves.

-gps
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20190215/e13d3015/attachment.html>