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