[Python-Dev] pathlib and issue 11406 (a directory iterator returning stat-like info) (original) (raw)

Ben Hoyt benhoyt at gmail.com
Mon Nov 25 04🔞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: http://bugs.python.org/issue19725 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.

Got it.

"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:

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.

-Ben

More information about the Python-Dev mailing list