Re: /usr/bin/python in Python 2 and 3

I think the basic shape of this idea is good - it's a neat way to keep the ubiquitous 'python' command available as Python 2 starts to go away, without breaking compatibility with all the scripts that expect that command to mean Python 2. You're essentially saying that 'python' can be Python 3, but only for scripts that deliberately opt into that behaviour. The opt-in mechanism is something that will be ignored if 'python' points to a regular Python interpreter and not the new loader.

One possible change I'd propose: rather than allowing a general specification of Python versions, perhaps it should be just a single 'python 3 is OK' flag. That keeps things simple, and makes it seem more like a transitional measure than a permanent feature. I don't see any specific problems with the version specifications, it just feels a bit like overdesign.

Using the environment variable is a neat way to provide ignored-by-default information, but don't forget it's also inherited-by-default. So if my script sets PYVERSIONS to allow 'python -c' to use Python 3, that will also affect anything it runs that doesn't explicitly set PYVERSIONS again, which could conceivably cause issues. I don't have a better proposal for that, though.

I assume the -m flag would use the same mechanism as -c.

These are all details that could be hashed out once a PEP is drafted, of course.

Thanks,

Thomas

On 17 April 2015 at 17:11, Geoffrey Thomas <geofft@ldpreload.com> wrote:

I've written up the proposal I made a few days ago for a /usr/bin/python launcher that keeps the API of being Python 2, but lets scripts opt in to running on Python 3:

https://ldpreload.com/blog/usr-bin-python-23

I share the desire for /usr/bin/python to maintain its API of being Python 2, but I also want to be able to write polyglot Python 2/3 scripts that run everyhwere -- including on Debian machines with just Python 3. So this is a way of "doing something else with /usr/bin/python" that's backwards-compatible for us and all the other distros. It even happens to be be kind of backwards-compatible for Arch, and Barry's point about aligning the desires of the distros is a very good one.

Let me know if you think this is a good or bad idea: I'll submit this as a PEP as soon as we have rough consensus that this is a good idea. (We can bikeshed the details once the idea itself is a draft PEP.)

--
Geoffrey Thomas
https://ldpreload.com
geofft@ldpreload.com

--
To UNSUBSCRIBE, email to debian-python-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: [🔎] alpine.DEB.2.10.1504171655000.18972@cactuar.ldpreload.com" target="_blank">https://lists.debian.org/[🔎] alpine.DEB.2.10.1504171655000.18972@cactuar.ldpreload.com