[Python-Dev] Re: New version of PEP 304

[James Kew]

Skip Montanaro wrote:
> I just checked in a new version of PEP 304.  It should be available at
>
>     http://www.python.org/peps/pep-0304.html
>
>> Feedback welcome. Windows C programmers even more welcome. ;-)

Cosmetic: there's a System Message: WARNING on the fourth bullet point of
"Proposal".

Serious: I'm not sure this covers all the bases on Windows, which has
multiple filesystem roots. Specifically, it doesn't preserve the current
behaviour if PYTHONBYTECODEBASE is not set and if the "startup drive" and
the drive on which a Python source file is located is not the same.

> If not defined, Python bytecode is generated in exactly the same way as is
currently done.
> sys.bytecodebase is set to the > root directory (either / on Unix or the
root directory of the
> startup drive -- typically C:\ -- on Windows).

Need to define "startup drive" precisely -- I assume something "the drive
from which the system is booted" or "the drive on which the operating system
is installed" (are these always the same?) but I don't know what the correct
terminology would be. "Startup drive" could be misinterpreted as "the drive
on which Python is installed", given that in the rest of the PEP "startup"
refers to Python or program startup.

OK: so if I don't set PYTHONBYTECODEBASE, sys.bytecodebase is set to C:\.

Now, what happens if I import a module which happens to be in, oh, for
example, D:\Roundup\MyTracker\config.py and which does not currently have
compiled bytecode alongside it?

> When the bytecode base is not None, a new bytecode file is written to the
appropriate augmented directory

BANG. The compiled bytecode is written not to
D:\Roundup\MyTracker\config.pyc as I would expect it to: instead, it's
magically and silently written to the "augmented" directory
C:\D\Roundup\MyTracker\config.pyc -- as a side-effect, unexpectedly creating
an new directory hierarchy on C:.

This needs to be fixed so that, on Windows, leaving PYTHONBYTECODEBASE
undefined yields the current behaviour as default -- as is already the case
when this PEP is implemented under Unix.

A suggestion: define a sys.bytecodebase of '/' to mean "default behaviour"
on Windows. This would normally be interpreted as "root of the current
drive" -- it's a little bit of a stretch to redefine it in this case as
"root of the source file's drive", but not unreasonable.

Taking this further, one could define that, on Windows, a sys.bytecodebase
containing a drive specifier specifies a single, systemwide bytecode
directory, with implicit directory augmentation; and that a sys.bytecodebase
that does not contain a drive specifier specifies a per-drive bytecode
directory. Thus:

sys.bytecodebase = "C:\Bytecode"

C:\MyStuff\script.py --> C:\Bytecode\C\MyStuff\script.pyc
D:\MyOtherStuff\demo.py --> C:\Bytecode\D\MyOtherStuff\demo.pyc

sys.bytecodebase = "\Bytecode"

C:\MyStuff\script.py --> C:\Bytecode\MyStuff\script.pyc
D:\MyOtherStuff\demo.py --> D:\Bytecode\MyOtherStuff\demo.pyc

I'm not sure this is entirely *useful* -- YAGNI? -- but it does then provide
a good basis for the default case:

sys.bytecodebase = "\"

C:\MyStuff\script.py --> C:\MyStuff\script.pyc
D:\MyOtherStuff\demo.py --> D:\MyOtherStuff\demo.pyc

Note also that this would imply a slight tweaking to "during program
startup, the value of the PYTHONBYTECODEBASE environment variable is made
absolute" to ensure that a drive specifier is not added to
PYTHONBYTECODEBASE if it does not already have one.

--
James Kew
james.kew@btinternet.com