PEP 3147 - new .pyc format
pavlovevidence at gmail.com
Sun Jan 31 01:14:53 CET 2010
On Jan 30, 2:14 pm, John Roth <johnro... at gmail.com> wrote:
> 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
I think it's a terrible, drastic approach to a minor problem. I'm not
sure why the simple approach of just appending a number (perhaps the
major-minor version, or a serial number) to the filename wouldn't
work, like this:
All I can think of is they are concerned with the typically minor
expense of listing the directory (to see if there's already .pyc??
file present). This operation can be reasonably cached; when scanning
a directory listing it need only record all occurrencs of .pyc?? and
mark those modules as subject to version-specific .pyc files. Anyway,
I'd expect the proposed -R switch would only be used in special cases
(like installation time) when a minor inefficiency would be tolerable.
> 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.)
This is utterly unacceptable. Versioned *.pyc files should only be
optionally requested by people who have to deal multiple versions,
such as distro package maintainers. For my projects I don't give a
flying F about versioned *.pyc and I don't want my project directory
cluttered with a million subdirectories. (It would be a bit more
tolerable if my directory was merely cluttered with *.pyc?? files, but
I'd still rather Python didn't do that unless asked.)
> 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.
How will this affect tools like Py2exe? Now you have a bunch of
identically-named *.pyc files.
> 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.
Now this just too much. I didn't like the suggestion that I should be
forced to put up with dozens of subdirectories, now you want me to
force me to put the source files into the subdirectories as well?
That would be a deal-breaker. Thankfully it is too ridiculous to ever
> Summary: I like it, but I think it needs a bit more work.
I hope it's replaced with something less drastic.
More information about the Python-list