On Jan 30, 2:14 pm, John Roth <johnro...@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 -- http://mail.python.org/mailman/listinfo/python-list
