[Python-Dev] [PEPs] Rebooting PEP 394 (aka Support the /usr/bin/python2 symlink upstream)

[Nick Coghlan]

On Fri, Aug 12, 2011 at 1:12 AM, Éric Araujo <merwok at netwok.org> wrote:
> I’m sorry if my opinion on that main point was lost among remarks on
> details.  To rephrase one part of my reply: Right now, the de facto
> standard is that shebangs can use python to mean python2 and python3 to
> mean python3.  Adding python2 to that and supporting making python
> ambiguous seems harmful to me.

This PEP comes mainly out of the fact that we collectively think Arch
(the case that prompted the original discussion) are making a mistake
that will hurt their users in switching the default Python *right
now*, so the PEP is first and foremost designed to record that
consensus. However, their actions do mean that the 'python' name is
*already* ambiguous, no matter what the mainstream distros think. The
Debian maintainers may not care about that, but *I* do, as does anyone
wanting to write distro-agnostic shebang lines.

Given that some distros (large or small), along with some system
administrators, are going to want to have python refer to python3,
either now or at some point in the future, there are really only two
options available to us here:

1. Accept the reality of that situation, and propose a mechanism that
minimises the impact of the resulting ambiguity on end users of Python
by allowing developers to be explicit about their target language.
This is the approach advocated in PEP 394.

2. Tell the Arch developers (and anyone else inclined to point the
python name at python3) that they're wrong, and the python symlink
should, now and forever, always refer to a version of Python 2.x.

It's worth noting that there has never been any previous python-dev
consensus to use 'python3' indefinitely - the status quo came about
because it makes sense for the moment even to those of us that *want*
'python' to eventually refer to 'python3', so there was no previous
need for an explicit choice between the two alternatives. By
migrating, Arch has forced us to choose between either supporting
their action or else telling Python users "Don't blame us, blame the
distros that pointed python at python3" when things break.

I flat out disagree with the second approach - having to type
'python3' when a 3.x variant is the only version of Python installed
would just be dumb, and I also think playing that kind of blame game
in the face of inevitable cross-distro compatibility problems is
disrespectful to our users. If you want to get Zen about it,
'practicality beats purity', 'explicit is better than implicit' and
'In the face of ambiguity, refuse the temptation to guess' all come
down in favour of the approach in PEP 394.

If I haven't persuaded you to adjust your view up to at least a -0
(i.e. don't entirely agree, but won't object to others moving forward
with it) and you still wish to advocate for the second approach, then
I suggest creating a competing PEP in order to provide a clear
alternative proposal (with Guido or his appointed delegate having the
final say, as usual) that explains the alternative recommendation for:
- distros that have already switched their 'python' links to refer to python3
- Python developers wishing to write shebang lines that work on
multiple 2.x versions and support both platforms that define 'python2'
and those that only define 'python'

FWIW, the closest historical precedent I can recall is Red Hat's
issues when users switched the system Python from 1.5 to 2.2+, and the
lesson learned from that exercise was that distro installed utilities
should always reference a specific Python version rather than relying
on the system administrator leaving the 'python' link alone. It sounds
like Debian chose not to heed that lesson, which is unfortunate
(although, to be honest, I'm not sure how well Fedora/Red Hat heed it,
either). However, the commentary in PEP 394 based on that history
(i.e. that distros really shouldn't care where the python name points)
will remain in place.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia