Is it worth back porting PEP 3147 to Python < 3.2?
Scott Kitterman
scott at kitterman.com
Tue Apr 20 21:57:56 BST 2010
On Monday, April 19, 2010 05:53:05 pm Barry Warsaw wrote:
> Apologies for the cross-post, but I want to make sure that everyone who
> cares about Python on both Debian and Ubuntu gets a chance to weigh in.
>
> On Friday, Guido approved and I landed the implementation of PEP 3147 on
> the py3k trunk (what will be Python 3.2). This allows multiple versions
> of Python to coexist on the same system without the need for symlinks to
> handle pyc file incompatibility.
>
> http://www.python.org/dev/peps/pep-3147/
>
> This will be officially supported in Python starting with 3.2. It will not
> however be available in upstream Python 2.7. The PEP does recognize
> however that distros may want to back port the feature to get its
> advantages now. Although I have not yet tried to do so, I think the
> essential elements of the PEP should be fairly easy to back port to Python
> 2.6, 2.7 and 3.1. The question is, should we do this?
>
> As the PEP outlines, my preference would be to back port it but *not*
> enable this by default in any Python < 3.2. Instead, the back port would
> add a -Xenablecachedir switch, and an associated $PYTHONENABLECACHEDIR
> environment variable that would have to be used to enable PEP 3147 pyc
> paths. Of course, this would have to be supported in python-support and
> python-central too, but I believe Piotr has started working on this.
>
> With the back port it means that any Python modules installed by apt will
> not need symlinks in order to share both the source and pyc locations.
> Normal Python developers working on their own code however would still get
> traditional pyc file locations by default (but of course, there would be
> nothing stopping them from setting the above switch/envar).
I think it is difficult to know for sure what the future will hold. If the
backport is not technically complex, I think a backport with the default to off
would be a nice tool in the box is things go differently than we plan. Other
than the effort involved, I don't see a downside, but I have no idea how hard
this would be to do.
Scott K
More information about the ubuntu-devel
mailing list