<div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 14, 2019 at 9:29 AM Barry Warsaw <<a href="mailto:barry@python.org">barry@python.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Feb 13, 2019, at 23:08, Matěj Cepl <<a href="mailto:mcepl@cepl.eu" target="_blank">mcepl@cepl.eu</a>> wrote:<br>
<br>
> Is this relevant to the discussion at hand? We are talking about<br>
> the binary /usr/bin/python3 which will be surely be provided<br>
> even by Python 4, won't it?<br>
<br>
Why would it be?  Since this is all hypothetical anyway <wink>, I’d more likely expect to only ship /usr/bin/python.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><div>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:</div></div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>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 <i>direct</i> #! line that works out of the box to launch a working latest version Python interpreter across all platforms.</div><div><br></div><div>The hack to make that work otherwise involves:</div><div><br></div><div>```sh</div><div>#!/bin/sh   # (or bash if that much is guaranteed)</div><div>... some shell logic to find _an_ acceptible interpreter ...</div><div>exec "${DISCOVERED_PYTHON}" - <<<END_OF_PYTHON_CODE</div><div># actual Python code here, escaped as appropriate when needed for being embedded within a shell script</div><div>END_OF_PYTHON_CODE</div><div>```</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>-gps</div></div></div></div>