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

[Éric Araujo]

Hi,

I’ve read the latest version of this PEP, as updated by Nick Coghlan in
the Mercurial repo on July, 20th.  Excuse me if I repeat old arguments,
I did not reread all the threads.

In summary, I don’t think the PEP is useful right now, nor that it will
set a good practice for the future.

> * Unix-like software distributions (including systems like Mac OS X and
Minor: I call these “operating systems”.

> * The Python 2.x ``idle``, ``pydoc``, and ``python-config`` commands should
>   likewise be available as ``idle2``, ``pydoc2``, and ``python2-config``,
>   with the original commands invoking these versions by default, but possibly
>   invoking the Python 3.x versions instead if configured to do so by the
>   system administrator.
This item ignores that on some OSes, defining the default Python version
is not a decision made by the sysadmin.  The example I know is Debian
(and derivatives): despite what one can read on the Web, it is not a
good idea to change /usr/bin/python to point to the version you want;
the decision affects all scripts used by the system itself, and is thus
the call of the Debian Python maintainers.  (FTR, Debian developers
discussed adding /usr/bin/python2 at the latest DebConf and rejected it;
I don’t know if the arguments raised are the same as mine, but maybe
Piotr or someone else will chime in in this thread.)

> This is needed as, even though the majority of distributions still alias the
> ``python`` command to Python 2, some now alias it to Python 3. Some of
> the former also do not provide a ``python2`` command; hence, there is
> currently no way for Python 2 code (or any code that invokes the Python 2
> interpreter directly rather than via ``sys.executable``) to reliably run on
> all Unix-like systems without modification, as the ``python`` command will
> invoke the wrong interpreter version on some systems, and the ``python2``
> command will fail completely on others. The recommendations in this PEP
> provide a very simple mechanism to restore cross-platform support, with
> minimal additional work required on the part of distribution maintainers.
I would like more data about this.  How many OSes have moved their
python executable to python2?  How much people does that impact?  Right
now I think that there’s only Arch and Gentoo, which I would call
minority platforms.  (I’m aware that all UNIX-like free operating
systems could be considered a minority OS all together, but we’re
talking about UNIX-like OSes here :)  Doing what the majority does is
not always a good thing, but for this PEP I think that numbers can help
us assess whether the trouble/benefit ratio is worth it.

In my opinion, the current situation is clear: python is some python2.y,
python3 is a python3.y, this is not ambiguous and will still work in ten
years when we get python4.  Thus, the previous decision of python-dev to
use python3 indefinitely seems good to me.  As a script/program author,
if I use python2 in my shebangs now to support what appears to be
minority platforms, I’m breaking compatibility with a huge number of
systems.  Therefore, I don’t see how this PEP makes the situation
better.  If one OS wants to change the meaning of the python command,
then its packaging tools should adapt shebangs, and its users should be
aware that the majority of existing Python 3 scripts will break.
Therefore, I’m strongly -1 on this PEP: changing the meaning of python
brings much trouble for little or no benefit, and adding python2 adds
another compatibility trouble.

It would be interesting to have feedback from people who lived the
transition to Python 2.

> * The ``pythonX.X`` (e.g. ``python2.6``) commands exist on some systems, on
>   which they invoke specific minor versions of the Python interpreter. It
>   can be useful for distribution-specific packages to take advantage of these
>   utilities if they exist, since it will prevent code breakage if the default
>   minor version of a given major version is changed. However, scripts
>   intending to be cross-platform should not rely on the presence of these
>   utilities, but rather should be tested on several recent minor versions of
>   the target major version, compensating, if necessary, for the small
>   differences that exist between minor versions. This prevents the need for
>   sysadmins to install many very similar versions of the interpreter.
Here again I would be interested in more numbers.  Pythons that people
manually download and install using the provided makefile do have these
pythonx.y executables, so I thought that all OSes did likewise.

Moreover, I disagree about the implied assertion that the minor number
hardly matters (I’m paraphrasing): Python 2.6 and 2.7 *are* different,
not “very similar”.  I don’t know very well the usages of the community,
but in my experience moving from 2.x to 2.x+1, or even just checking
that your code still works, is a Big Deal.  I’d like this whole bullet
item to be removed.

> Impact on PYTHON* Environment Variables
I think this section should be named PYTHONPATH, as it is the only
envvar that it talks about.  Another minor edit: s/folder/directory/

Regards