On 04/27/18 02:03, Ben Finney wrote: > Ben Finney <ben+python at benfinney.id.au> writes: > >> Petr Viktorin <encukou at gmail.com> writes: >> >>> […] we feel that the only way to *enforce* that guidelines is to >>> provide environments where the `python` command does not work >>> (unless explicitly installed). >> >> Yes. The ‘python’ command is confusing, for the reasons you say. There >> should be ‘python2’ and ‘python3’ commands for Python 2 and Python 3 >> respectively, and no ‘python’ command should be installed by the >> operating system. >> >> The fact that ‘/usr/bin/python’ exists is an historical accident, and I >> agree with the proposal you state: the best way to correct the confusion >> is to bar the confusing command from being installed by packages. > > Because the above is ambiguous, I'll clarify: I am not calling for, and > PEP 394 does not call for, the banishment of the ‘python’ command. Well, Guido *is* calling for it :) It would break too many things, but after discussions on the PR, it's clear that we want a future where the "python" doesn't exist. But while it's available, it should point to Python 2. > What I'm saying is that muddying the rules further on what ‘python’ may > or may not mean is *worse than* banishing the ‘python’ command entirely. That's also consistent with the PR discussion. (But not that much with the original PEP, which said `python` is expected to eventually mean `python3`.) > So, short of banishing ‘python’ entirely, I think PEP 394 is already a > good clear way to address the issue. Existing, documented and supported > means to locally modify a ‘python’ command already exist and should be > sufficient. > >> I trust that PEP 394 will not be weakened in its effect, and I wish you >> well with using the already-supported, already-documented, PEP-394 >> compatible means to add local customisations for a ‘python’ command. Right. But some already-supported, already-documented mechanisms like Debian Alternatives or alternate package repos, are not compatible with PEP 394. And as a PEP 394 compliant distro, we also won't be promoting the /usr/local or $HOME/bin ways to change `python` (which makes me a bit sad, because that documentation might have included a link to the caveats listed in the PEP).
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4