PEP 3147 - new .pyc format

Daniel Fetchinson fetchinson at googlemail.com
Mon Feb 1 05:14:42 EST 2010


> PEP 3147 has just been posted, proposing that, beginning in release
> 3.2 (and possibly 2.7) compiled .pyc and .pyo files be placed in a
> directory with a .pyr extension. The reason is so that compiled
> versions of a program can coexist, which isn't possible now.
>
> Frankly, I think this is a really good idea, although I've got a few
> comments.
>
> 1. Apple's MAC OS X should be mentioned, since 10.5 (and presumably
> 10.6) ship with both Python release 2.3 and 2.5 installed.
>
> 2. I think the proposed logic is too complex. If this is installed in
> 3.2, then that release should simply store its .pyc file in the .pyr
> directory, without the need for either a command line switch or an
> environment variable (both are mentioned in the PEP.)
>
> 3. Tool support. There are tools that look for the .pyc files; these
> need to be upgraded somehow. The ones that ship with Python should, of
> course, be fixed with the PEP, but there are others.
>
> 4. I'm in favor of putting the source in the .pyr directory as well,
> but that's got a couple more issues. One is tool support, which is
> likely to be worse for source, and the other is some kind of algorithm
> for identifying which source goes with which object.

I also think the PEP is a great idea and proposes a solution to a real
problem. But I also hear the 'directory clutter' argument and I'm
really concerned too, having all these extra directories around (and
quite a large number of them indeed!). How about this scheme:

1. install python source files to a shared (among python
installations) location /this/is/shared
2. when python X.Y imports a source file from /this/is/shared it will
create pyc files in its private area /usr/lib/pythonX.Y/site-packages/
Time comparison would be between /this/is/shared/x.py and
/usr/lib/pythonX.Y/site-packages/x.pyc, for instance.

Obviously pythonX.Y needs to know the path to /this/is/shared so it
can import modules from there, but this can be controlled by an
environment variable. There would be only .py files in
/this/is/shared.

Linux distro packagers would only offer a single python-myapp to
install and it would only contain python source, and the
version-specific pyc files would be created the first time the
application is used by python. In /usr/lib/pythonX.Y/site-packages
there would be only pyc files with magic number matching python X.Y.

So, basically nothing would change only the location of py and pyc
files would be different from current behavior, but the same algorithm
would be run to determine which one to load, when to create a pyc
file, when to ignore the old one, etc.

What would be wrong with this setup?

Cheers,
Daniel


-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown



More information about the Python-list mailing list