Ben Finney wrote:
Kristján Valur Jónsson <kristjan@ccpgames.com> writes:
Repeatedly we run into trouble because of stray .pyo (and/or .pyc) files. This can happen for a variety of reasons, but most often it occurs when .py files are being removed, or moved in the hierarchy. The problem is that the application will happily load and import an orphaned .pyo file, even though the .py file has gone or moved.
Yes, I think Python users would benefit from having the above behaviour be opt-in.
Agreed. This has bitten me, too. Often when it's a permissions problem where another user has created the .pyc file and I can't overwrite it (this on Windows).
I suggest:
* A new attribute ‘sys.import_orphaned_bytecode’. If set ‘True’, the interpreter follows the current behaviour. If ‘False’, any bytecode file satisfies an import only if it has a corresponding source file (where “corresponding” means “this source file would, if compiled, result in a bytecode file replacing this one”).
I agree with this in principle, but I don't see how you're going to implement it. In order to actually check this condition, aren't you going to have to compile the source code anyway? If so, just skip the bytecode file. Although I guess you could store a hash of the source in the compiled file, or other similar optimizations.
I suggest this attribute should be implemented as ‘True’ by default (to match current behaviour), then switched to ‘False’ by default as soon as feasible.
* The ‘PYTHONIMPORTORPHANEDBYTECODE’ environment variable, when set, causes the interpreter to set the above option ‘True’.
* The ‘-b’ option to the interpreter command-line sets the above option ‘True’.
Sounds good to me. Eric.