Re: /usr/bin/python in Python 2 and 3
On Sat, 18 Apr 2015, Scott Kitterman wrote:
I like it and I don't. If /usr/bin/python is ever going to point to a non-
python2 version, then I think the solution is something like this. OTOH, it
adds system complexity and presumably slows interpreter startup.
If the implementation were simple enough and well enough tested, then I think
the complexity concern is not a major issue. Interpreter startup time is a
big deal in some applications, so that merits some investigation before anyone
decides this is "the" solution to the problem.
I wrote a proof-of-concept implementation of the algorithm, to time the
effect. (I mostly say "proof-of-concept" since I feel guilty about
hand-coded string parsing in C....) Anecdotally, testing 1000 runs of
`python -c True` on my machine takes around 10.5-12 seconds without the
wrapper, and around 11-12.5 seconds with the wrapper, so I'm not inclined
to be too concerned. The wrapper is 200 lines of C, which could be reduced
with a decent string library.
https://github.com/geofft/pythonmux
By the way, note that this could be built into future versions of the
Python 3 interpreter executable. It's backwards-compatible for Python 3 to
live at /usr/bin/python, as long as it attempts to exec Python 2 (or
prints a useful error) whenever basename(argv[0]) is "python" and there's
no metadata indicating Python 3 support. This avoids the extra exec for
Python 3 applications.
Alternatively, maybe applications that are sensitive about interpreter
startup time should just call `/usr/bin/python3` (or `python2`) directly.
In a world with this multiplexer, `python` would be only a compatibility
interface used by things that need to run on Python 2 in some places and
Python 3 in other places.
I wonder if dh_python3 could at some point parse the magic line to assist in
dependency generation.
That would be useful! I do think there's value in having the metadata of
Python minor version compatibility, even in a world where major version
isn't a problem anymore.
--
Geoffrey Thomas
https://ldpreload.com
geofft@ldpreload.com
Reply to: