Is it worth back porting PEP 3147 to Python < 3.2?

Barry Warsaw barry at
Thu Apr 22 18:52:11 BST 2010

On Apr 21, 2010, at 12:01 AM, Piotr Ożarowski wrote:

>2to3 is not reliable, at least not for now.

I agree that there's no way we can just enable it by default.  Too many
upstream packages need modifications to work in Python 3.  However, for those
that are Python 3-ready, it's a useful tool.  The question then is whether we
want to enable it for those packages that it works with.

>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...)

How much of the transition testing is automated?  It would be very interesting
for example, to have a test framework that could run any combination of Python
packages against various versions of Python, and get a report on the success
or failure of it.  This may not be a project for the distros of course - I
think upstream Python would be very interested in something like this.  For
example, a tool that grabbed packages from the Cheeseshop and tested them
against different versions would be cool.  If ever gets off the
ground, that might be the best place to put something like this together
(though we'd care less about OSes that aren't Debian and Ubuntu).

>> 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/
> /usr/share/python3/foo/
> /usr/share/python3/foo/3.2-/
> /usr/share/python3/3.1-3.5/

Those are the symlinks, right?  E.g. /usr/share/python3/foo/3.2-/ would
symlink to /usr/shared/pyshared/

I like the idea of shipping symlinks, but I thought they were created at
runtime to handle the case where a new version of Python was installed after
the package was installed.  Is that the case, and if so, wouldn't all the
packages have to be updated when a new version of Python is supported?

>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 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

:).  I'll look those up.

>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.

Thanks for the links.  I'd like to help in any way I can.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
Url : 

More information about the ubuntu-devel mailing list