Re: /usr/bin/python in Python 2 and 3
On 2 May 2015 at 13:39, Geoffrey Thomas <geofft@ldpreload.com> wrote:
> 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.
This still seems like a profoundly poor idea: 'is X python3
compatible' is a turing completeness problem. There are some scripts
where you can determine compatibility, but many where you cannot until
it blows up (particularly ones with subtle bugs in string type
correctness).
IMO Folks existing scripts should be left to use python, but
encouraged to used python2 if they can't be changed to python3, and
new scripts should just use python3.
-Rob
--
Robert Collins <rbtcollins@hp.com>
Distinguished Technologist
HP Converged Cloud
Reply to: