[Python-Dev] My summary of the scandir (PEP 471)
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 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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev