On Mon, 19 Nov 2018 at 21:21, Petr Viktorin <encu...@gmail.com> wrote: > (Wow, am I glad to be legally allowed to talk about this now!)
It does make it much easier than having to dance around what the plans for RHEL 8 actually were (especially since they weren't the same as Fedora's plans, so the usual escape hatch didn't work). > That leaves advantages of "py" to: > - "py" is shorter (and many people already use it as a custom shortcut!) > - "py" is consistent with Windows (which is would be great for > classes/workshops, provided it doesn't make installation harder) > - plus something about distributions like Anaconda, which I don't know > much about The main advantage I see to "py" is that it's deliberately ambiguous about the exact target version (and can be made to favour Python 3 from the start), whereas "python" has had a much longer history of referring to some variant of Python 2.x. It's also the case that if cross-distro Py 2/3 source-compatible scripts start saying "/usr/bin/py", then it's straightforward to add a symlink to older systems that resolves to the same target as /usr/bin/python, even without adding the launcher. > I'd update the PEP to allow flat-out leaving out "/usr/bin/python". That > way, users will get the "command not found" error message, which I > believe to be the most straightforward, easy to spot, easy to fix and > easy to workaround way to get out of this mess. My initial reaction was "Doesn't it already say that?", but the answer is no, it doesn't, since the bullet point about leaving the symlink out entirely says this: ============= In controlled environments aimed at expert users, where being explicit is valued over user experience (for example, in test environments and package build systems), distributions may choose to not provide the python command even if python2 is available. (All software in such a controlled environment must use python3 or python2 rather than python, which means scripts that deliberately use python need to be modified for such environments.) ============= The counterargument to the idea that it's OK to not offer *any* standard way of exposing a link or launcher that gives you some arbitrary version of Python available on the system is this open "Python interpreter autodiscovery" issue for Ansible: https://github.com/ansible/ansible/issues/45852 At the moment, there's no clear answer as to what to put into the shebang lines of Python scripts that are cross-distro compatible, and also source-compatible with Python 2 & Python 3: - "/usr/bin/python" (and variants like "/usr/bin/env python") will fail on RHEL/CentOS 8 and any system without Python 2 installed - "/usr/bin/python3" (and variants) will fail on RHEL/CentOS 7 (unless py3 has been installed from EPEL) - "/usr/bin/python2" (and variants) will fail in the same places "/usr/bin/python" fails, and more besides (since not all distros with Python 2.x have a python2 symlink) The other downside of "/usr/bin/python" is the one you mentioned: it's ambiguous about the script author's intent, since "actively maintained and Py3 compatible" has the same spelling as "hasn't been touched in years". So if we were to amend the PEP to say that "/usr/bin/py" should exist, and refer to either: - the Python Launcher for Unix; or - some version of Python 3.x (or any later Python version); or - Python 2.7 (if there isn't a more recent version of Python installed) Then we could also give script shebang line authors clearer guidance on what to use: - /usr/bin/python2 for scripts that definitely don't work on Python 3.x - /usr/bin/python3 for scripts that definitely don't work on Python 2.x - /usr/bin/python for single source scripts that seek broad compatibility with older systems running Python 2.x - /usr/bin/py for single source scripts that seek forward compatibility with newer systems (and also with older systems that have been configured to support it) > P.S. minor semantic nitpick: please don't call the last round of changes > to PEP 394 "Petr's updates". It was a compromise. My updates would be > much more radical :) Heh, fair point - I only called them that since you were the main driver behind them, and they also marked the point where you became a co-author on the PEP. I'll call them the 2018 updates, since I doubt we're going to change the guidance in the next few weeks. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Linux-sig mailing list -- linux-sig@python.org To unsubscribe send an email to linux-sig-le...@python.org https://mail.python.org/mailman3/lists/linux-sig.python.org
