[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

Reply to: