[Python-Dev] pathlib and issue 11406 (a directory iterator returning stat-like info)
benhoyt at gmail.com
Mon Nov 25 04:18:47 CET 2013
> The idea of the rich stat result object is that has all that info
> prepopulated, based on an initial stat call. "Caching" it amounts to "keep a
> reference to it".
> It is suggested that it would be a subset of the pathlib.Path API:
> If it's also a superset of the existing stat object API, then at least
> Path.stat and Path.lstat (and perhaps the lower level APIs) can be updated
> to return it in 3.5.
>> "Worst case", we can add os.scandir() separately, which return
>> DirEntry, "path-like" objects.
> Indeed, we may still want such an object API, since dirent doesn't provide
> full stat info.
I'm not quite sure what you're suggesting here.
In any case, I'm going to modify my scandir() so its DirEntry objects
are closer to pathlib.Path, particularly:
* isdir() -> is_dir()
* isfile() -> is_file()
* islink() -> is_symlink()
* add is_socket(), is_fifo(), is_block_device(), and is_char_device()
I'm considering removing DirEntry's .dirent attribute entirely. The
above is_* functions cover everything in .dirent.d_type in a much more
Pythonic and cross-platform way, and the only other info in .dirent is
d_ino -- can a non-Windows dev tell me how or when d_ino would be
useful? If it's useful, is it useful in a higher-level, cross-platform
API such as scandir()?
Hmmm, I wonder about this "rich stat object" idea in light of the
above. Do the methods on pathlib.Path basically supercede the need for
this? Because otherwise folks will always be wondering whether to say
"path.is_dir()" or "path.stat().is_dir" ... two ways to do it, right
next to each other. So I'd prefer to add the "rich" stuff on the
higher-level Path instead of the lower-level stat.
> A PEP reviewing all this for 3.5 and proposing a specific os.scandir API
> would be a good thing.
Thanks, I'll definitely consider writing a PEP.
More information about the Python-Dev