On Wed, Dec 9, 2009 at 02:22, Nick Coghlan <ncoghlan@gmail.com> wrote:
Ben Finney wrote:
Right, that's what I thought. I was only looking for a way to say “only use a bytecode file if the corresponding source code file exists”, and then trying to define “corresponding source code file”.
As Guido said, the check goes the other way: the interpreter looks for source files first, and if it doesn't find one, only then does it look for orphaned bytecode files (pyo/pyc).
Just a data point: I reversed that order in importlib to match mental semantics.
The check for a corresponding bytecode files after a source file has actually been found follows a different path through the import code.
Since the two features are somewhat orthogonal, slicing out the check for orphaned bytecode files while keeping the check for a cached bytecode file should be fairly straightforward.
Fair warning to anyone that implements this - expect to be updating quite a few parts of the test suite. The runpy, command line, import and zipimport tests would all need to be updated to make sure they were respecting the flag (and probably the importlib tests as well, at least in Py3k).
Yep for importlib, but I already protect bytecode-writing tests with a decorator for sys.dont_write_bytecode, so doing this for tests that rely on reading bytecode could easily be decorated as well. -Brett