PEP 304 - Controlling generation of bytecode files

[Skip Montanaro]

    Dennis> Why not "pyc_dir" as a shorter name?

I've already shortend it to "bytecodebase".  Guido didn't want it too
short. ;-)

    Dennis> This PEP does not address explicitly how the user can change the
    Dennis> env.  variable during startup. Suppose I code in my main module:

    Dennis>     sys.pythonbytecodebase = ""
    Dennis>     import file01
    Dennis>     import file02
    Dennis>     sys.pythonbytecodebase = "outdir/subdir"
    Dennis>     import file03
    Dennis>     ....  #etc.

    Dennis> does this give file by file control?

As someone else pointed out, only if neither file01 nor file02 import
file03.  In any case, my intent here is *not* to provide file-by-file
control over .pyc writes.

    Dennis> What I would really want is directory by directory control.  I
    Dennis> am importing from the following example structure

This is also not the intent of this PEP.

    Dennis> I would like a clean way to treat pyc files in dirA one way and
    Dennis> dirB another without chasing down every import.  For example:

    Dennis>     sys.pyc_dir = {"dirA":"", dirB:"output/dir/path", ".":"some/other/path"}

Again, this is beyond the scope or intention of the PEP.  Perhaps you can
accomplish what you want with an import hook.  See PEP 302.

    Dennis> once at the beginning would give all the control I would want.
    Dennis> Perhaps there is a way to incorporate file by file control in a
    Dennis> single statement also.

That's really not the aim of the PEP.  I'll make that explicit in the next
revision of the document.  The original motivation for the PEP was to
provide a reasonable way for multiple processes to not step on one anothers'
toes when .pyc files were generated, either by suppressing .pyc writes
altogether or by specifiying process-specific directory trees so writes
would be isolated from other processes.

Skip