On 9/26/18 12:19 PM, Nick Coghlan wrote:
> On Wed, 26 Sep 2018 at 00:49, Barry Warsaw <barry(a)python.org> wrote:
>> On Sep 24, 2018, at 05:48, Sorin Sbarnea <ssbarnea(a)redhat.com> wrote:
>>> I would like to propose a change on PEP 394 recommendations which were originally made almost 7 years ago when python3 was bleeding edge for most distributions.
>> The last time this topic came up, we essentially deferred changing PEP 394 until after Python 2’s official EOL date. I think that’s still appropriate. Once Python 2 is for good and ever retired, then it’s worth considering changes to PEP 394’s language.
> Yep, this is still where Fedora is at as well - step 1 is to eliminate
> legacy references to the python symlink, and then step 2 will be to
> figure out if/when it ever comes back as a way of referring to a
> generic version of Python.
Actually, step 1 is done, minus stragglers that are hard to find and
won't switch until things break for them.
I would be fine switching "python" to Python 3 in Fedora 30 (which is
being developed now, and will be supported into 2020), but only if we
agree it's the thing to do -- and I consider PEP 394 to be the place for
core dev consensus.
> Personally, I suspect it's more likely that we''ll start shipping
> https://github.com/brettcannon/python-launcher with CPython at some
> point, similar to the way we ship the original py launcher for
I have doubts that would help. Until `py` is everywhere, you'll still
have different ways to start Python on different systems, and `py -3`
vs. `python3` is, frankly, not much of a difference.
I would like to propose a change on PEP 394 recommendations which were originally made almost 7 years ago when python3 was bleeding edge for most distributions.
Now almost all major distributions are switching to python3 by default and not installing python2 in their base deployment.
They also seem careful to follow PEP 394 which is a good thing to do. Still, the side effect of this is that based on that they do *not* create the symlink between python -> python3 which means a newly spawned machine would give "command not found" when trying to run `python`.
The lack of default breaks lots of tools which only need one python interpreter to run, regardless its version.
One notable issue is Ansible where users would be forced to do extra steps for controlling new machines with only python3 on them.
https://github.com/ansible/ansible/issues/45852 <https://github.com/python/peps/pull/785> -- yep, not being able to cleanly run configuration management may create a chicken and the egg issue, as users would want to use it to configure the machine.
Other examples are any scripts that now will not be able to ship with a generic shebang line. It would be impossible to make a generic python script executable to run on all platforms, even if the code itself would work without problems.
I may also mention the (in)famous usage of `curl <url> | python` approach which is popular. Without having a "python" command, developers would have to
update the documentation to mention the use of python or python3 based on the platform (creating more work which may be avoidable).
If PEP recommendation would be made more generic, and to suggest distribution publishers to provide a python symlink to whichever is the default interpreter on their current OS release, we could easily avoid this cascade of changes that would provide a poor UX.
I raised a first version of that update at https://github.com/python/peps/pull/785 <https://github.com/python/peps/pull/785>
Arch Linux made the decision to implement this regardless the PEP. Instead of going the path of ignoring it it, wouldn't be much better if we would improve it so it can be followed by everyone without clearly bad side-effects for the endusers?