[Python-Dev] Updates to PEP 471, the os.scandir() proposal (original) (raw)
Ethan Furman ethan at stoneleaf.us
Wed Jul 9 19:38:38 CEST 2014
- Previous message: [Python-Dev] Updates to PEP 471, the os.scandir() proposal
- Next message: [Python-Dev] Updates to PEP 471, the os.scandir() proposal
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 07/09/2014 10:10 AM, Paul Moore wrote:
On 9 July 2014 14:22, Ben Hoyt <benhoyt at gmail.com> wrote:
One issue with option #2 that I just realized -- does scandir yield the entry at all if there's a stat error? It can't really, because the caller will except the .lstat attribute to be set (assuming he asked for type='lstat') but it won't be. Is effectively removing these entries just because the stat failed a problem? I kind of think it is. If so, is there a way to solve it with option #2? So the issue is that you need to do a stat but it failed. You have "whatever the OS gave you", but can't get anything more. This is only an issue on POSIX, where the original OS call doesn't give you everything, so it's fine, those POSIX people can just learn to cope with their broken OS, right? :-)
LOL
More seriously, why not just return a DirEntry that says it's a file with a stat entry that's all zeroes? That seems pretty harmless. And the onerror function will be called, so if it is inappropriate the application can do something. Maybe it's worth letting onerror return a boolean that says whether to skip the entry, but that's as far as I'd bother going.
I could live with this -- we could enhance it the future fairly easily if we needed to.
--
Ethan
- Previous message: [Python-Dev] Updates to PEP 471, the os.scandir() proposal
- Next message: [Python-Dev] Updates to PEP 471, the os.scandir() proposal
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]