[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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 

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