Skip Montanaro wrote: > I wrote PEP 304, "Controlling Generation of Bytecode Files": ... > If someone out there is interested in this functionality > and would benefit more from its incorporation into the > core, I'd be happy to hand it off to you.
I am quite interested in this PEP. What, exactly, would the recipient of this "hand-off" have to do? Does it primarily have to do with resolution of the issues listed in the PEP? BTW, my use case for this PEP is different than the PEP's given rationale -- in general, I (and the people I work with) keep our source trees completely separate from (and parallel to) our object trees. This obviates the need for .cvsignore, makes "make clean" a much easier proposition, makes it easier to generate and test/compare slightly different object sets (just use an environment variable to change the build target directory), and reduces the filtration required to get usable output from simple source file greps. The main fly in the ointment right now is .pyc files -- they tend to pop up whereever there is a little script (or more accurately, of course, whereever there is a multiple-module script :), and the current choices for dealing with them as special cases, e.g. zip files, copying all sub-modules over to the build tree before importing them, manually reading the files and compiling them, etc., are all rather unappealing. >From my perspective, the lack of PEP 304 functionality in the standard distribution is hampering World Domination, since the littering of source directories with compiled .pyc files is yet another excuse for some of my compatriots to keep using Perl. In fact, I have to be very careful how I introduce Python scripts into this environment lest I anger someone by polluting their source tree. Note that for my current purposes (as described above, and in contrast to the original rationale behind the PEP) sys.bytecodebase is much more important than PYTHONBYTECODEBASE (because my few scripts can set up sys.bytecodebase quite easily themselves). Since it would seem that most of the security concerns would derive from the PYTHONCODEBASE environment variable, it would be an interesting exercise to try to figure out how many potential users of this PEP want it for my purposes and how many want it for the original purpose. I would think not adding the environment variable would be less contentious from a security/backward-compatibility standpoint, but possibly more contentious from a lack-of-new-useful-functionality-that-could-not-be-easily-implemented-in-an-add-on-package standpoint. Regards, Pat -- http://mail.python.org/mailman/listinfo/python-list
