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