PEP 304 - is anyone really interested?

[Patrick Maupin]

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