PEP 304 - Controlling generation of bytecode files

[Skip Montanaro]

    Terry> 1. I understand the 'python' prefix for the environmental
    Terry>    variable (PYTHONBYTECODEBASE) but it seems unnecessary and
    Terry>    overdone for the sys attribute.  sys.bytecodebase is enough to
    Terry>    write already and is quite sufficient for identifying the
    Terry>    contents.

Point taken.  The change is in v. 1.7.

    Terry> 2. I am not familiar with all the os.path funcs.  If pcb is
    Terry>    C:/tem/py and I import sys, for instance, would it write
    Terry>    C:/tem/py/sys.pyc or C:/tem/py/..../.../sys.pyc?  One actual
    Terry>    example would be helpful.

There are several in the PEP (see the subsection titled "Examples" ;-).  The
answer is, the latter.  I clarified the examples in v. 1.7.  They all
mention "augmented directory", which is defined in the glossary at the
start, but the exact values it takes on should have been specified in the
examples.

    Terry> 3. This proposal changes behavior globally but does not address
    Terry>    the issue of doing so on a per file basis.

That's not the intent of this PEP.  It's hard for me to think of a use case
for module-by-module control over where to write .pyc files.  Can you
suggest one?

    Terry> 3b. A suggestion I sent to pydev (not sure if it arrived) would be
    Terry>     another .pyx extension such as .pyf for py-final, meaning
    Terry>     "this python code is the last (and only) version we want to
    Terry>     see on the file system -- do not write anything else -- .pyc,
    Terry>     .pyo, or any future version of processed code".

I don't remember this suggestion.  Still, what happens if foo.py is updated
and foo.pyf exists?  Do you always import from foo.py and never write the
byte code?

Skip