[Python-Dev] Bilingual scripts
barry at python.org
Wed May 29 20:34:18 CEST 2013
On May 28, 2013, at 12:23 PM, Toshio Kuratomi wrote:
>> 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
><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
>I've been looking at how Fedora's ruby guidelines are implemented wrt
>alternate interpreters and wondering if we could do something similar for
Very interesting. It was something like this, albeit replacing _jruby_ or
_mri_ with something like --py2 or --py3 that I had in mind. However...
>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.
... it kind of gives me the heebie-jeebies too. I think *most* scripts
wouldn't need this kind of variability though. For example, lsb_release only
needs to run with one version of Python, so:
% head -1 /usr/bin/lsb_release
#! /usr/bin/python3 -Es
is just fine. I wouldn't want to replace /usr/bin/python with a selectable
interpreter (see also PEP 394), but if we had something like /usr/bin/multipy
which acted like rubypick for the few, very limited examples where it's
needed, then it might be useful to do so.
I would very definitely want to get consensus on the mechanism and api between
the various Linux distros here so it works the same on F/RH, D/U, Gentoo and
>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.
Seems like for Python, that would be the most important use case, but maybe I
have blinders on for the issue at hand.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: not available
More information about the Python-Dev