[Python-Dev] Bilingual scripts

Nick Coghlan ncoghlan at gmail.com
Wed May 29 05:01:57 CEST 2013


On Wed, May 29, 2013 at 5:23 AM, Toshio Kuratomi <a.badger at gmail.com> wrote:
> On Tue, May 28, 2013 at 01:22:01PM -0400, Barry Warsaw wrote:
>> On May 27, 2013, at 11:38 AM, Toshio Kuratomi wrote:
>>
>> >- 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
>> territory.
>>
> <nod>  This is an interesting, unmapped area in Fedora at the moment... I
> was hoping to talk to Nick and the Fedora python maintainer at our next
> Fedora conference.
>
> I've been looking at how Fedora's ruby guidelines are implemented wrt
> alternate interpreters and wondering if we could do something similar for
> python:
>
> https://fedoraproject.org/wiki/Packaging:Ruby#Different_Interpreters_Compatibility
>
> I'm not sure yet how much of that I'd (or Nick and the python maintainer
> [bkabrda, the current python maintainer is the one who wrote the rubypick
> script]) would want to use in python -- replacing /usr/bin/python with a
> script that chooses between CPython and pypy based on user preference gave
> me an instinctual feeling of dread the first time I looked at it but it
> seems to be working well for the ruby folks.
>
> My current feeling is that I wouldn't use this same system for interpreters
> which are not mostly compatible (for instance, python2 vs python3).  but I
> also haven't devoted much actual time to thinking about whether that might
> have some advantages.

PEP 432 is also related, as it includes the "pysystem" proposal [1]
(an alternate Python CLI that will default to -Es behaviour, but is
otherwise similar to the standard "python" interpreter).

The rest of the discussion though makes me think we may actually need
a *nix equivalent of PEP 397 (which describes the "py" launcher we
created to get around the limitations of Windows file associations).

Between that and the interpreter identification mechanism defined for
the PEP 425 compatibility tags it should be possible to come up with
an upstream solution for 3.4 that the distros can backport to work
with earlier versions (similar to the way users can download the
Windows launcher directly from
https://bitbucket.org/pypa/pylauncher/downloads even though we only
started shipping it upstream as part of the Python 3.3 installer)

Cheers,
Nick.

[1] http://www.python.org/dev/peps/pep-0432/#a-system-python-executable


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


More information about the Python-Dev mailing list