brett at python.org
Mon Mar 1 21:37:10 CET 2010
On Mon, Mar 1, 2010 at 08:30, Ron Adam <rrr at ronadam.com> wrote:
> Nick Coghlan wrote:
>> Michael Foord wrote:
>>> Can't it look for a .py file in the source directory first (1st stat)?
>>>> When it's there check for the .pyc in the cache directory (2nd stat,
>>>> magic number encoded in filename), if it's not check for .pyc in the
>>>> source directory (2nd stat + read for magic number check). Or am I
>>>> missing a subtlety?
>>> The problem is doing this little dance for every path on sys.path.
>> To unpack this a little bit for those not quite as familiar with the
>> import system (and to make it clear for my own benefit!): for a
>> top-level module/package, each path on sys.path needs to be eliminated
>> as a possible location before the interpreter can move on to check the
>> next path in the list.
>> So the important number is the number of stat calls on a "miss" (i.e.
>> when the requested module/package is not present in a directory).
>> Currently, with builtin support for bytecode only files, there are 3
>> checks (package directory, py source file, pyc/pyo bytecode file) to be
>> made for each path entry.
>> The PEP proposes to reduce that to only two in the case of a miss, by
>> checking for the cached pyc only if the source file is present (there
>> would still be three checks for a "hit", but that only happens at most
>> once per module lookup).
>> While the PEP is right in saying that a bytecode-only import hook could
>> be added, I believe it would actually be a little tricky to write one
>> that didn't severely degrade the performance of either normal imports or
>> bytecode-only imports. Keeping it in the core import, but turning it off
>> by default seems much less likely to have unintended performance
>> consequences when it is switched back on.
>> Another option is to remove bytecode-only support from the default
>> filesystem importer, but keep it for zipimport (since the stat call
>> savings don't apply in the latter case).
> What if ... a bytecode-only mode is triggered by "__main__" loading from a
> bytecode file, otherwise the .py files are needed and are checked to make
> sure the bytecode files are current.
That's way too magical for my tastes, especially if you mess up and
accidentally leave behind a __main__.pyc after moving the __main__.py file.
> Python-Dev mailing list
> Python-Dev at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev