Re: Is it worth back porting PEP 3147 to Python < 3.2?
[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
Reply to: