[Python-Dev] Updates to PEP 471, the os.scandir() proposal
Ben Hoyt
benhoyt at gmail.com
Mon Jul 14 02:12:16 CEST 2014
More information about the Python-Dev mailing list
Mon Jul 14 02:12:16 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 ]
>> Very much agreed that this isn't necessary for just readdir/FindNext >> errors. We've never had this level of detail before -- if listdir() >> fails half way through (very unlikely) it just bombs with OSError and >> you get no entries at all. >> >> If you really really want this (again very unlikely), you can always >> use call next() directly and catch OSError around that call. > > Agreed - I think the PEP should point this out explicitly, and show that the > approach it takes offers a lot of flexibility in error handling from "just > let it fail", to a single try/catch around the whole loop, to try/catch just > around the operations that might call lstat(), to try/catch around the > individual iteration steps. Good point. It'd be good to mention this explicitly in the PEP and have another example or two of the different levels of errors handling. > os.walk remains the higher level API that most code should be using, and > that has to retain the current listdir based behaviour (any error = ignore > all entries in that directory) for backwards compatibility reasons. Yes, definitely. -Ben
- 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 ]
More information about the Python-Dev mailing list