On 2/14/19 9:56 AM, Petr Viktorin wrote:
On 2/13/19 4:24 PM, Petr Viktorin wrote:
I think it's time for another review.
[...]
Please see this PR for details and a suggested change:
https://github.com/python/peps/pull/893
Summary of the thread so far.
Antoine Pitrou noted that the PEP should acknowledge that there are now
years of
established usage of `python` as Python 3 for many conda users, often as
the "main" Python.
Victor Stinner expressed support for "python" being the latest Python
version, citing PHP, Ruby, Perl; containers; mentions of "python" in our
docs.
Steve Dower later proposed concrete points how to make "python" the
default command:
* our docs should say "python" consistently
* we should recommend that distributors use the same workaround
* our docs should describe the recommended workaround in any places
people are likely to first encounter it (tutorial, sys.executable, etc.)
Chris Barker added that "python3" should still be available, even if
"python" is default.
Barry Warsaw gave a +1 to making "python" default, noting that there
were plans to change this when Python 2 is officially deprecated. But
distros need to make decisions about 2020 now.
Chris Barker noted that users won't see any discuntinuity in 2020.
That's just a date support from CPython devs ends.
Victor pointed to discussions on 4.0 vs. 3.10. (I'll ignore discussions
on 4.0 in this summary.)
Victor also posted some interesting info and links on Fedora and RHEL.
There was a discussion on the PSF survey about how many people use
Python 3. (I'll ignore this sub-thread, it's not really about the
"python" command.)
Steve noted that the Windows Store package of Python 3 provides
"python", but he is still thinking how to make this reasonable/reliable
in the full installer.
Several people think "py" on Unix would be a good thing. Neil
Schemenauer supposes we would encourage people to use it over
"python"/"python2"/"python3", so "python" would be less of an issue.
Neil Schemenauer is not opposed to making "python" configurable or
eventually pointing it to Python 3.
Jason Swails shared experience from running software with a
"#!/usr/bin/env python" shebang on a system that didn't have Python 2
(and followed the PEP, so no "python" either). The workaround was ugly.
There haven't been many new ideas since this summary – mostly it was
explaining and re-hashing what's been mentioned before.
Matthias Klose pointed out some Debian/Ubuntu points, to which I'll add
the situation in other distros I know of.
*Debian* is concerned that python → python3 will break software
after an upgrade. Debian appears to not want to ship the unversioned
command after py2 removal.
For *Ubuntu*, Matthias is not sure if he wants a python executable at
all. He notes that pypi.org recommends pip, and pip still breaks
system-installed packages when asked to.
For both Ubuntu 20.04 LTS and Debian bullseye, the goal is that distro
packages don't use the unversioned shebang.
*Fedora* packages don't use the unversioned shebang. If it was up to me,
the unversioned command would be removed in F31 (released in the first
half of 2019) and then pointed to python3 in F32 (second half). But we'd
rather happy to follow upstream consensus. (And the PEP, if it reflects
the consensus.)
In *RHEL*, the unversioned command is missing by default. Sysadmins can
change it, but are advised to use python2/python3 instead. RHEL decision
makers don't give the PEP much weight.
*Arch* did the switch to python3 a long time ago (and the resulting fire
wasn't all that bright).
With *Homebrew*, `python` points to Homebrew’s Python 2.7.x (if
installed) otherwise the macOS system Python. That's exactly according
to the PEP. They tried to switch python to python3 before, and got
rather nasty backlash citing PEP 394. I assume they will follow the PEP
quite strictly from now on.
The *macOS* system Python is out of our hands; Apple ignores upstream
recommendations.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
