<p dir="ltr"><br>
On 25 Nov 2013 09:31, "Ben Hoyt" <<a href="mailto:benhoyt@gmail.com">benhoyt@gmail.com</a>> wrote:<br>
><br>
> > It's also quite likely the "rich stat object" API will be pursued for 3.5,<br>
> > which is a much safer approach to stat result caching than trying to embed<br>
> > it directly in pathlib.Path objects.<br>
><br>
> As a Windows dev, I'm not sure I love the "rich stat object idea",<br>
> because stat_result objects are sooo Posixy. On Windows, (some of) the<br>
> file attribute info is stuffed into a stat_result struct. Which kinda<br>
> works, but I like how Path exposes the higher-level, cross-platform<br>
> stuff like .is_dir() so that most of the time you don't need to worry<br>
> about stat. (You still need to worry about caching, though.)</p>
<p dir="ltr">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".</p>
<p dir="ltr">It is suggested that it would be a subset of the pathlib.Path API: <a href="http://bugs.python.org/issue19725">http://bugs.python.org/issue19725</a></p>
<p dir="ltr">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.</p>
<p dir="ltr">> > That's why we decided to punt on the caching question until 3.5 - it's<br>
> > better to provide a predictable building block that doesn't provide caching,<br>
> > and then work out how to provide a sensible caching layer on top of that,<br>
> > rather than trying to rush a potentially flawed caching design that leads to<br>
> > inconsistent behaviour.<br>
><br>
> Yep, agreed about rushing in a potentially flawed caching design. But<br>
> I also don't want to "rush in" a design that prohibits scandir()-style<br>
> performance optimizations -- though I guess it can still go in there<br>
> one way or the other.</p>
<p dir="ltr">Yeah, the realisation that an initial non-caching approach didn't lock us out of external caching may not have been well communicated to the list. I was discussing the walkdir integration possibilities with Antoine and Guido and realised I would likely still need an external cache, even if pathlib had its own internal caching. At that point, it seemed highly desirable to duck the caching question entirely.</p>

<p dir="ltr">> "Worst case", we can add os.scandir() separately, which return<br>
> DirEntry, "path-like" objects.</p>
<p dir="ltr">Indeed, we may still want such an object API, since dirent doesn't provide full stat info.</p>
<p dir="ltr">A PEP reviewing all this for 3.5 and proposing a specific os.scandir API would be a good thing.</p>
<p dir="ltr">Cheers,<br>
Nick.</p>
<p dir="ltr">><br>
> -Ben<br>
</p>