[Python-Dev] possibility of shaving a stat call from imports

Tim Delaney timothy.c.delaney at gmail.com
Fri Oct 18 23:12:11 CEST 2013


On 19 October 2013 03:53, Brett Cannon <brett at python.org> wrote:

> importlib.machinery.FileFinder does a stat call to check if a path is a
> file if the package check failed. Now I'm willing to bet that the check is
> rather redundant as the file extension should be a dead give-away that
> something in a directory is a file and not some non-file type. The import
> would still fail even if this is the case in the loader when attempting to
> read from the file, but it happens a little later and it means finders
> would be more permissive in claiming they found a loader.
>
> Does anyone see a good reason not to take the more optimistic route in the
> finder? As I said, the only thing I see breaking user code is if they have
> a directory or something named spam.py and so the finder claims it found a
> module when in fact it didn't and thus stopping the search for the module
> from continuing.
>

Whilst directories with extensions are unusual on Windows, they're fairly
common on UNIX-based systems. For example, blah.rc directories. And I
personally often create directories with extensions - usually a timestamp
of some kind.

If the extension is specifically an extension that Python uses (e.g.
.py[cod]) then I think it would be reasonable to make the assumption and
let the import fail at the loader instead. Would the extension check be
faster or slower than another stat() call?

As an alternative, is there another stat call later that could be bypassed
if you temporarily cached the result of this stat call? And if so, when
should the cached value be cleared?

Tim Delaney
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131019/074d31e5/attachment.html>


More information about the Python-Dev mailing list