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

[Nick Coghlan]

On 25 Nov 2013 13:18, "Ben Hoyt" <benhoyt at gmail.com> wrote:
>
> > 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:
>
> * 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.

The rich stat API proposal exists precisely to provide a clean way to do
stat result caching - path objects always give immediate data, stat objects
give cached answers.

The direct APIs on Path would just become a trivial shortcut once a rich
stat APIs existed - you could use the long form if you wanted to, but it
would be pointless to do so.

Cheers,
Nick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20131125/1653148a/attachment.html>