On 07/31/2017 04:25 PM, Barry Warsaw wrote:
[...]
The message we want to send is: "everything that can be ported to Python 3
should be ported, and everything that can run on Python 3 should run on it.”
+1
However, having /usr/bin/python point to Python 2 is continuing the concrete mindset for
Linux users that "the default" version of Python is still Python 2.
Those mixed signals are especially problematic with maintainers that aren't
familiar with the Python ecosystem (e.g. they only use a Python-based
buildsystem).
IMHO, the reason why this is so is because `python` (at the prompt, a.k.a.
typically /usr/bin/python) is the CLI API for *users*. It’s what they’re
taught to type at the command line to run their scripts or to start the
interpreter to play with things.
PEP 394 already recommends `python2` and `python3` in the shebang line for
distro-provided executables. I think we turn some SHOULDs into MUSTs so that
any PEP-394 compliant *nix distro will be required to follow the same rules.
Further, I’d add that PEP 394-compliant distros MUST NOT put /usr/bin/python in
shebangs.
+1
Ah, yes, this is missing from the "PEP 548" pull request.
(PEP 394 does not talk about `/usr/bin/env python` which is often used by
developers, although highly discouraged for distro-provided scripts, at least
in Debian. If we want to add a note about this, I think we make it clear that
this usage relies solely on the user’s own $PATH environment, and therefore
lies outside the scope of the PEP.)
+1
I’d like to discourage the use of naming schemes like `idle2`, `pydoc2`, etc.
That’s a problematic approach, for which -m invocation is much more
predictable, albeit less convenient. We still don’t have a good solution for
that, although many have been discussed. That’s probably outside the scope of
PEP 394 too.
I think that ship has sailed. The unversioned names should switch along
with /usr/bin/python, and the versioned ones should be allowed to die
along with /usr/bin/python[23]. Improving the -m situation is out of scope.
Lastly, we come to what /usr/bin/python points to, and that’s always been the
sticking point. There are two use cases.
* When people type that at the command line, which version of Python do they
get?
* When people use that in their own third-party (i.e. not distro-provided)
scripts, what version of Python do they get?
So, it’s a UI/UX problem now :)
> I would personally like to say /usr/bin/python will always point to
python3 after such-and-such a date, although as I’ve said above, my
timing would put that to later in 2020. However, I think we need to
allow distributions to make their own decisions on that timing. Some
may choose to never make it, others may be proactive.
There are two ways to go here. Either we can make it a MUST to point
/usr/bin/python to python3, and just label any distro that decides otherwise as
“non-PEP-394-compliant”, or we make the choice more lax (possibly SHOULD,
possibly MAY) and allow leeway for otherwise in-compliance distros. I suspect
there will be some in Debian that will argue for the latter, and they will make
good points. OTOH, I think we’re well past the tipping point, and will face
the cliff pretty darn soon. I haven’t completely made my own mind up on this
point. In the meantime, I think we can make a lot of progress on PEP 394 as
I’ve outlined above.
The other recommendations proposed here are designed so they can be
implemented right now, with no bad side effects, but switching
/usr/bin/python will break things. I think here it's good to leave the
timing up to distros, and to suggest that the distros allow users to
override their decisions.
_______________________________________________
Linux-sig mailing list
Linux-sig@python.org
https://mail.python.org/mailman/listinfo/linux-sig
