RetroSearch Browse

Thu Feb 4 22:51:35 CET 2010 · https://mail.python.org/pipermail/python-dev/2010-February/097428.html

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).

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()

For the import machinery itself, setting __compiled__ would be the
responsibility of the loaders due to the way load_module is specified. 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.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2010-February/097428.html below:

[Python-Dev] PEP 3147: PYC Repository Directories