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 >> 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
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 any others. >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. -Barry
signature.asc
Description: PGP signature
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
