On Mon, 16 Sep 2013 19:06:37 +0200
Charles-François Natali <cf.natali@gmail.com> wrote:
> 2013/9/16 Antoine Pitrou <solipsis@pitrou.net>:
> > Le Sun, 15 Sep 2013 06:46:08 -0700,
> > Ethan Furman <ethan@stoneleaf.us> a écrit :
> >> I see PEP 428 is both targeted at 3.4 and still in draft status.
> >>
> >> What remains to be done to ask for pronouncement?
> >
> > I think I have a couple of items left to integrate in the PEP.
> > Mostly it needs me to take a bit of time and finalize the PEP, and
> > then have a PEP delegate (or Guido) pronounce on it.
>
> IIRC, during the last discussion round, we were still debating between
> implicit stat() result caching - which requires an explicit restat()
> method - vs a mapping between the stat() method and a stat() syscall.
>
> What was the conclusion?

No definite conclusion. You and Nick liked the idea of a rich stat
object (returned by os.stat()) with is_dir() methods and the like:
https://mail.python.org/pipermail/python-dev/2013-May/125809.html

However, nothing was done about that since then ;-)

There was also the scandir() proposal to return rich objects with
optional stat-like fields, but similarly it didn't get a conclusion:
https://mail.python.org/pipermail/python-dev/2013-May/126119.html

So I would like to propose the following API change:

- Path.stat() (and stat-accessing methods such as get_mtime()...)
  returns an uncached stat object by default

- Path.cache_stat() can be called to return the stat() *and* cache it
  for future use, such that any future call to stat(), cache_stat() or
  a stat-accessing function reuses that cached stat

In other words, only if you use cache_stat() at least once is the
stat() value cached and reused by the Path object.
(also, it's a per-Path decision)