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

[Nick Coghlan]

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 ensure_lstat keyword param to scandir if you need the
> > lstat_result 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.
>
>
> > .lstat_result 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>