On 19 October 2013 03:53, Brett Cannon <br...@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
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
