[Python-Dev] PEP 3147: PYC Repository Directories (original) (raw)

Brett Cannon brett at python.org
Thu Feb 4 23:16:36 CET 2010

On Thu, Feb 4, 2010 at 13:51, Nick Coghlan <ncoghlan at gmail.com> wrote:

Brett Cannon wrote: > My thinking is we deprecate getfilename() and introduce some new method > that returns a two-item tuple (getpaths?). First item is where the > source should be, and the second is where the bytecode is if it exists > (else it's None). Putting both calculations into a single method seems > better than a sourcepath()/bytecodepath() as the latter would quite > possibly need sourcepath() to call bytecodepath() on its own to > calculate where the source should be if it doesn't exist on top of the > direct call to getbytecode() for setting compiled itself.

If we add a new method like getfilenames(), I would suggest going with Antoine's suggestion of a tuple for compiled (allowing loaders to indicate that they actually constructed the runtime bytecode from multiple cached files on-disk). Does code exist out there where people are constructing bytecode from multiple files for a single module?

The runpy logic would then be something like:

try: method = loader.getfilenames except AttributeError: compiled = () try: method = loader.getfilename except: file = None else: file = method() else: file, *compiled = method() 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.

For the import machinery itself, setting compiled would be the responsibility of the loaders due to the way loadmodule is specified.

Yep.

I still sometimes wonder if we would be better off splitting that method into separate "preparemodule" and "execmodule" methods to allow the interpreter a chance to fiddle with the module globals before the module code gets executed.

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.

But yes, given a do-over, I would abstract loaders to a finer grain to let import handle more of the details.

-Brett

Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia --------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20100204/1d375f81/attachment-0001.htm>

More information about the Python-Dev mailing list