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