[Barry Warsaw, 2010-04-20] > On Apr 20, 2010, at 10:14 AM, Piotr Ożarowski wrote: > > >[Omer Zak, 2010-04-20] > >> My take of the situation: > >> Yes, please backport PEP 3147 to at least Python 2.7. > >> The rationale: we'll need to support both Python 2.x and Python 3.x for > >> several years, and it will be nice if the same library package can be > >> made to support both 2.x and 3.x. > > > >you cannot (in most cases) share 2.X and 3.X Python code, so adding it > >to 2.7 and not to 2.6 doesn't make sense > > Just thinking out loud: How insane would it be to think of an import hook that > could do it at run time?
2to3 is not reliable, at least not for now. Example: even today I backported Python 3 related patch from tip and upstream *did* test it with 2to3 and python3.X before releasing Python 3.X compatible version. The second python3-* package I maintain doesn't provide Python extension for now, as it didn't even build for 3.X version; module (that had to use custom 2to3 rules, BTW) uses it optionally, though. If it doesn't always work with modules tested with python3, I'm pretty sure it will not always work with modules written when python3.X wasn't even released upstream so runtime conversion is not acceptable, IMHO. Every maintainer has to check the module before providing python3-foo package and that requires manpower Ubuntu doesn't have. That's why Python transitions in Ubuntu didn't work that well in the past (I don't recall a single one completed before Debian, and Ubuntu started with 2.6 few years before us...) > But > I would like to know more about your new dh_python, what changes it would > require, etc. Where can I find it, or information about it? it will ship symlinks instead of creating them at runtime (and use list of exceptions instead of shipping a list of files to compile) in "old" mode and in PEP3147 mode, paths like: /usr/share/python3/foo/__init__.py /usr/share/python3/foo/bar.py /usr/share/python3/foo/3.2-/bar.py /usr/share/python3/3.1-3.5/baz.py using __path__ to choose the right source file (like in the example[1] I gave you the other day). Note that right now it requires changing __init__.py file and that's where namespace PEP comes in (and new .pth files). See threads on debian-python mailing list with "dh_python" in Subject for more info, some things changed since then (and I'm too sleepy right now to list them :-P), though What changes it will require? Well, I plan to provide wrappers that will emulate dh_pycentral/dh_pysupport's API, but as recent site-packages -> dist-packages transition showed - every package has to be checked by its maintainer (there are lots of corner cases not easy to predict like depending on helper tool's internal paths) Right now only pycompile[2] and pyclean[3] are available in public. [1] http://people.debian.org/~piotr/__path__.tar.gz [2] http://people.debian.org/~piotr/pycompile [3] http://people.debian.org/~piotr/pyclean -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100420220108.go6...@piotro.eu
