Re: PyCon BoF: Stretch goals for cPython, PyPy & CFFI
I'm trying to make sure I understand this subthread correctly. Is the
following an accurate summary of the desires?
1. It should be possible, in Debian, not to ship Python 2 by default in
the near future, and to remove Python 2 from the archive in the far
future.
2. A huge number of existing/"legacy" scripts use #!/usr/bin/env python or
perhaps #!/usr/bin/python to mean Python 2. Until at least 2020 (when
Python 2.7 is desupported), it should be possible to install Python 2.7,
whether through the package manager or otherwise, and have these scripts
run correctly. If this is done, it should not break unrelated things in
Debian, like Python 3.x-only scripts that ship with Debian.
3. It should be possible for authors of new both-Python-2-and-3 source to
write scripts so that they run on both an existing/"legacy" machine with
Python 2.x installed only, and on future machines with Python 3.x
installed only. "Legacy" machines will have Python 2 at /usr/bin/python,
and no wrapper. Future machines might have a wrapper. (For instance, it's
OK if the mechanism to solve this does not address current Ubuntu releases
that ship Python 3 only by default.)
I think this is solvable by defining a standard to identify polyglot
Python 2/3 source. For instance, say that polyglot scripts should start
#!/usr/bin/env python
# py23
and add a wrapper in /usr/bin (perhaps via dpkg-divert) that checks to see
if the second line of its input is "# py23" (or /^# *py23$/, or
something). If so, it execs Python 3; if not, and if it can't find Python
2, it prints a useful error to stderr and exits. (For interactive use, it
could print a warning and run Python 3, or silently exec Python 3, or
something.)
--
Geoffrey Thomas
https://ldpreload.com
geofft@ldpreload.com
Reply to: