[Python-Dev] My summary of the scandir (PEP 471) (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Tue Jul 1 17:33:06 CEST 2014


On 1 Jul 2014 07:31, "Victor Stinner" <victor.stinner at gmail.com> wrote:

2014-07-01 15:00 GMT+02:00 Ben Hoyt <benhoyt at gmail.com>:

> 2) Nick Coghlan's proposal on the previous thread > (https://mail.python.org/pipermail/python-dev/2014-June/135261.html) > suggesting an ensurelstat keyword param to scandir if you need the > lstatresult value

I don't like this idea because it makes error handling more complex. The syntax to catch exceptions on an iterator is verbose (while: try: next() except ...).

Actually, we may need to copy the os.walk API and accept an "onerror" callback as a scandir argument. Regardless of whether or not we have "ensure_lstat", the iteration step could fail, so I don't believe we can just transfer the existing approach of catching exceptions from the listdir call.

Whereas calling os.lstat(entry.fullname()) is explicit and it's easy to surround it with try/except.

> .lstatresult being None sometimes (on POSIX), Don't do that, it's not how Python handles portability. We use hasattr().

That's not true in general - we do either, depending on context.

With the addition of an os.walk style onerror callback, I'm still in favour of a "get_lstat" flag (tweaked as Ben suggests to always be None unless requested, so Windows code is less likely to be inadvertently non-portable)

> would it ever really happen that readdir() would succeed but an os.stat() immediately after would fail?

Yes, it can happen. The filesystem is system-wide and shared by all users. The file can be deleted.

We need per-iteration error handling for the readdir call anyway, so I think an onerror callback is a better option than dropping the ability to easily obtain full stat information as part of the iteration.

Cheers, Nick. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20140702/accff437/attachment.html>



More information about the Python-Dev mailing list