[Python-Dev] Bilingual scripts

Barry Warsaw barry at python.org
Tue May 28 19:22:01 CEST 2013

On May 27, 2013, at 11:38 AM, Toshio Kuratomi wrote:

>Fedora is a bit of a mess... we try to work with upstream's intent when
>upstream has realized this problem exists and have a single standard when
>upstream does not.  The full guidelines are here:

Thanks.  One of the reasons I've brought this up here is so that hopefully we
can come up with recommendations for upstreams where this matters.

One thing is for sure (IMO, anyway).  Utilities that provide version-specific
scripts should also provide -m invocation.  E.g. there are various places
where a package's tests (provided unittest, or other as-built tests) can be
invoked.  Where those might use nose, we recommend invoking them with
`$python -m nose` instead using nosetests-X.Y.  This also makes it easier to
loop over all the versions of Python available on the system (which might not
be known statically).

>- If upstream doesn't deal with it, then we use a "python3-" prefix.  This
>    matches with our package naming so it seemed to make sense.  (But
>    Barry's point about locate and tab completion and such would be a reason
>    to revisit this... Perhaps standardizing on /usr/bin/foo2-python3
>    [pathological case of having both package version and interpreter
>    version in the name.]

Note that the Gentoo example also takes into account versions that might act
differently based on the interpreter's implementation.  So a -python3 suffix
may not be enough.  Maybe now we're getting into PEP 425 compatibility tag

>  - (tangent from a different portion of this thread: we've found that this
>    is a larger problem than we would hope.  There are some obvious ones
>    like
>    - ipython (implements a python interpreter so python2 vs python3 is
>      understandably important ad different). 
>    - nosetests (the python source being operated on is run through the
>      python interpreter so the version has to match).
>    - easy_install (needs to install python modules to the correct
>      interpreter's site-packages.  It decides the correct interpreter
>      according to which interpreter invoked it.)
>    But recently we found a new class of problems:  frameworks which are
>    bilinugual.  For instance, if you have a web framework which has a
>    /usr/bin/django-admin script that can be used to quickstart a
>    project, run a python shell and automatically load your code, load your
>    ORM db schema and operate on it to make modifications to the db then
>    that script has to know whether your code is compatible with python2 or
>    python3.


>> I think the simplest thing to do is just append the "3" to the binary
>> name (as we do ourselves for pydoc) and then abide by the
>> recommendations in PEP 394 to reference the correct system executable.
>I'd rather not have a bare 3 for the issues notes above.  Something like py3
>would be better.

Same here.  I definitely don't like the current Debian semi-convention (not
standardized or consistent) of injecting a '3' in the middle of the name,
e.g. py3compile or py3doc.

Note that adopting PEP 425 conventions allows for -py3 suffix to mean any
Python 3 version, compatible across minor version numbers or implementations.
This probably translates into a shebang line of

#! /usr/bin/python3

whereas -py33 would mean

#! /usr/bin/python3.3

This might be overkill in some cases, but at least it builds on existing

>There's still room for confusion when distributions have to push multiple
>versions of a package with scripts that fall into this category.  Should the
>format be:
>/usr/bin/foo2-py3  (My preference as it places the version next to the
>    thing that it's a version of.)
>/usr/bin/foo-py3-2  (Confusing as the 2 is bare.  Something like
>    /usr/bin/foo-py3-v2 is slightly better but still not as nice as the
>    previous IMHO)

Definitely the former, especially if PEP 425 serves at the basis for


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130528/c105766b/attachment.pgp>

More information about the Python-Dev mailing list