On Mon, Mar 1, 2010 at 08:30, Ron Adam <r...@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.

-Brett




> Ron
>
>
>
>
>
>
> _______________________________________________
> 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/brett%40python.org
>
_______________________________________________
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

Reply via email to