PEP 304 - Controlling generation of bytecode files
skip at pobox.com
Wed Jan 29 19:50:57 CET 2003
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
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
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
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
More information about the Python-list