[Python-Dev] PEP 394 update proposal: Allow changing the `python` command in some cases

[Petr Viktorin]

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).