On Thu, Feb 4, 2010 at 13:51, Nick Coghlan <ncogh...@gmail.com> wrote:
> Brett Cannon wrote: > > My thinking is we deprecate get_filename() and introduce some new method > > that returns a two-item tuple (get_paths?). 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 source_path()/bytecode_path() as the latter would quite > > possibly need source_path() to call bytecode_path() on its own to > > calculate where the source should be if it doesn't exist on top of the > > direct call to get_bytecode() for setting __compiled__ itself. > > If we add a new method like get_filenames(), 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.get_filenames > except AttributeError: > __compiled__ = () > try: > method = loader.get_filename > 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 load_module is specified. Yep. > I > still sometimes wonder if we would be better off splitting that method > into separate "prepare_module" and "exec_module" 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 | ncogh...@gmail.com | Brisbane, Australia > --------------------------------------------------------------- >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
