<br><br><div class="gmail_quote">On Thu, Feb 4, 2010 at 13:51, 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">Brett Cannon wrote:<br>
> My thinking is we deprecate get_filename() and introduce some new method<br>
> that returns a two-item tuple (get_paths?). First item is where the<br>
> source should be, and the second is where the bytecode is if it exists<br>
> (else it's None). Putting both calculations into a single method seems<br>
> better than a source_path()/bytecode_path() as the latter would quite<br>
> possibly need source_path() to call bytecode_path() on its own to<br>
> calculate where the source should be if it doesn't exist on top of the<br>
> direct call to get_bytecode() for setting __compiled__ itself.<br>
<br>
</div>If we add a new method like get_filenames(), I would suggest going with<br>
Antoine's suggestion of a tuple for __compiled__ (allowing loaders to<br>
indicate that they actually constructed the runtime bytecode from<br>
multiple cached files on-disk).<br>
<br></blockquote><div><br></div><div>Does code exist out there where people are constructing bytecode from multiple files for a single module?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
The runpy logic would then be something like:<br>
<br>
try:<br>
method = loader.get_filenames<br>
except AttributeError:<br>
__compiled__ = ()<br>
try:<br>
method = loader.get_filename<br>
except:<br>
__file__ = None<br>
else:<br>
__file__ = method()<br>
else:<br>
__file__, *__compiled__ = method()<br>
<br></blockquote><div><br></div><div>Should it really be a flat sequence that get_filenames returns? That first value has a very special meaning compared to the rest which suggests to me keeping the returned sequence to two items, just with the second item being a sequence itself.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
For the import machinery itself, setting __compiled__ would be the<br>
responsibility of the loaders due to the way load_module is specified.</blockquote><div><br></div><div>Yep.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I<br>
still sometimes wonder if we would be better off splitting that method<br>
into separate "prepare_module" and "exec_module" methods to allow the<br>
interpreter a chance to fiddle with the module globals before the module<br>
code gets executed.<br></blockquote><div><br></div><div>There's a reason why importlib has its ABCs abstracted the way it does; there's a bunch of stuff that can be automated and is common to all loaders that load_module has to cover. We could consider refactoring the API, but I don't know if it is worth the hassle since importlib has decorators that take care of low-level commonality and has ABCs for higher-level stuff.</div>
<div><br></div><div>But yes, given a do-over, I would abstract loaders to a finer grain to let import handle more of the details.</div><div><br></div><div>-Brett</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Cheers,<br>
Nick.<br>
<font color="#888888"><br>
--<br>
Nick Coghlan | <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a> | Brisbane, Australia<br>
---------------------------------------------------------------<br>
</font></blockquote></div><br>