Hi! 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? Thanks Sorin Sbarnea
_______________________________________________ Linux-sig mailing list Linux-sig@python.org https://mail.python.org/mailman/listinfo/linux-sig
