<br><br><div class="gmail_quote">On Wed, Dec 9, 2009 at 02:22, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im">Ben Finney wrote:<br>
> Right, that's what I thought. I was only looking for a way to say “only<br>
> use a bytecode file if the corresponding source code file exists”, and<br>
> then trying to define “corresponding source code file”.<br>
<br>
</div>As Guido said, the check goes the other way: the interpreter looks for<br>
source files first, and if it doesn't find one, only then does it look<br>
for orphaned bytecode files (pyo/pyc).<br>
<br></blockquote><div><br></div><div>Just a data point: I reversed that order in importlib to match mental semantics.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">


The check for a corresponding bytecode files after a source file has<br>
actually been found follows a different path through the import code.<br>
<br>
Since the two features are somewhat orthogonal, slicing out the check<br>
for orphaned bytecode files while keeping the check for a cached<br>
bytecode file should be fairly straightforward.<br>
<br>
Fair warning to anyone that implements this - expect to be updating<br>
quite a few parts of the test suite. The runpy, command line, import and<br>
zipimport tests would all need to be updated to make sure they were<br>
respecting the flag (and probably the importlib tests as well, at least<br>
in Py3k).<br></blockquote><div><br></div><div>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.</div>

<div><br></div><div>-Brett </div></div>