> 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.

">

(original) (raw)


On 1 Jul 2014 07:31, "Victor Stinner" <victor.stinner@gmail.com> wrote:
\>
\> 2014-07-01 15:00 GMT+02:00 Ben Hoyt <benhoyt@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.