Re: [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  writes:


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


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Ben Finney]

Ben Finney  writes:

> Petr Viktorin  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.

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.

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.

-- 
 \   “Try to learn something about everything and everything about |
  `\  something.” —Thomas Henry Huxley |
_o__)  |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Ben Finney]

Petr Viktorin  writes:

> In Fedora, I found that PEP 394's strict recommendation that `python`
> points to `python2` is holding us back.

I have read the message, but I don't see how you draw the link that PEP
394 is holding you back.

> The problems are:
> - For developers that are not following the language's development,
> the fact that `python` invokes `python2` sends a strong signal that 2
> is somehow the preferred version, and it's OK to start new projects in
> it.

I agree with the statement you make later in the message:

> […] 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.

> - Users and sysadmins that *do* want to “live in the future” are
> switching the symlink to `python3` themselves. We would like to give
> them a supported, documented way to do so -- and make surer they're
> aware of the caveats.

The supported, documented way to add a command pointing to a different
command already exists, and there is no need to make a Python-specific
special case.

Users who want to make a ‘python’ alias can do so in their shell; this
is supported and documented.

Users who want to add a new command file can add a suitable directory
(e.g. ‘$HOME/bin’) to their ‘PATH’ variable, and put a symlink in there
named ‘python’. This is supported and documented.

Sysadmins who want to create a system-wide command ‘python’ can put a
symlink at ‘/usr/local/bin/python’. This is supported and documented.

I disagree with making some special-case extra way; that would be both
cunfusing and superfluous.

> - The `python` command is still not available out-of-the box on macOS,
> so it didn't completely live up to the expectation of being the
> cross-platform way to launch 2/3 source compatile scripts.

That is one of the minor ways which macOS fails to conform to
community-agreed conventions. We should not let that intransigence
distort our discussion of best practices.

> To help solve these, I would like to relax recommendations on the Unix
> ``python -> python2`` symlink in these cases:

For the above reasons, I disagree that PEP 394 is limiting what you want
to do on free-software operating systems.

For non-free operating systems, I don't think the already-discussed PEP
394 should be weakened if the operating system vendor fails to conform.

> - Users and administrators can, by a deliberate action, change
> ``python`` to invoke Python 3.

Yes. That is well-known and long-standardised on Unix operating systems,
and is much more broadly understood than any Python-specific special
case would be. So I don't see how anyone is being held back.

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.

-- 
 \  “Pity the meek, for they shall inherit the earth.” —Donald |
  `\  Robert Perry Marquis |
_o__)  |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Petr Viktorin]

Hello,
In Fedora, I found that PEP 394's strict recommendation that `python` 
points to `python2` is holding us back. From discussions on Zulip and 
elsewhere it's clear that this recommendation is not changing any time 
soon, but I would like to officially relax it in several cases.


The problems are:
- For developers that are not following the language's development, the 
fact that `python` invokes `python2` sends a strong signal that 2 is 
somehow the preferred version, and it's OK to start new projects in it.
- Users and sysadmins that *do* want to “live in the future” are 
switching the symlink to `python3` themselves. We would like to give 
them a supported, documented way to do so -- and make surer they're 
aware of the caveats.
- The `python` command is still not available out-of-the box on macOS, 
so it didn't completely live up to the expectation of being the 
cross-platform way to launch 2/3 source compatile scripts.
- `python` in the shebang line can mean *either* that a script is 
carefully written to be 2/3 compatible, *or* that the author/maintainer 
is lazy or unaware of the recommendations. While Fedora guidelines have 
long banned the unversioned command, we feel that the only way to 
*enforce* that guidelines is to provide environments where the `python` 
command does not work (unless explicitly installed).


To help solve these, I would like to relax recommendations on the Unix 
``python -> python2`` symlink in these cases:


- Users and administrators can, by a deliberate action, change 
``python`` to invoke Python 3. (Activating a venv counts as such an 
action, but so would e.g. using alternates, installing a non-default 
overriding package, or replacing /usr/bin/python.)
- In controlled environments where being explicit is valued more than 
user experience (test environments, build systems, etc.), distributions 
can omit the `python` command even when `python2` is installed.


I have filed these changes as a pull request here:

  https://github.com/python/peps/pull/630

The PR also spells out several other things, which I felt were hidden 
between the lines -- but correct me if you disagree with my reading.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com