PEP 3147 - new .pyc format

[Carl Banks]

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


-1

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:

foo.pyc25

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


> Summary: I like it, but I think it needs a bit more work.

I hope it's replaced with something less drastic.


Carl Banks