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

Gregory P. Smith greg at krypto.org
Mon Feb 18 12:28:21 EST 2019


On Mon, Feb 18, 2019, 7:34 AM Matthias Klose <doko at ubuntu.com wrote:

> On 16.02.19 00:15, Gregory P. Smith wrote:
> > 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).
>
> There is no notion of a "core" for Debian. So "core" applies to the whole
> distro, as long as there are python shebangs found.
>
> For Ubuntu, you don't have a python command on the default desktop
> install, just
> python3.  Trying to invoke python, command-not-found tells you:
>
>   $ python
>
>   Command 'python' not found, but can be installed with:
>
>   [...]
>
>   You also have python3 installed, you can run 'python3' instead.
>
> That tells you which way to go.
>

"Core" just means part of the minimal install, needed by startup scripts
and the package manager perhaps. This would be a default install with no
package groups selected or perhaps the netinst image for Debian. If
packages in that set don't need a python interpreter, Debian is in great
shape! :)


> > 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.
>
> If you count the above example towards this "mistake", probably yes. But
> there
> is *no* way to have a sane way to have what you want.
>

Agreed.

In the long run, expecting python 2 to exist is not sane.  But given our
pep394 text of "for the time being, all distributions *should* ensure that
python, if installed, refers to the same target as python2," What Debian
has done is still unfortunately encouraged by us.

We've created a world where #! lines cannot be used to invoke an
intentionally compatible script across a wide variety of platforms over
time. But our decision to do that was the decision to have an incompatible
release in the first place.

Too late now. :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20190218/9cc9dcf5/attachment.html>


More information about the Python-Dev mailing list