[Python-Dev] PEP 428: Pathlib -> stat caching (original) (raw)
Antoine Pitrou solipsis at pitrou.net
Wed Sep 18 10:26:43 CEST 2013
- Previous message: [Python-Dev] PEP 428: Pathlib -> stat caching
- Next message: [Python-Dev] PEP 428: Pathlib -> stat caching
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Le Tue, 17 Sep 2013 18:10:53 -0700, Philip Jenvey <pjenvey at underboss.org> a écrit :
On Sep 16, 2013, at 1:05 PM, Antoine Pitrou wrote: > On Mon, 16 Sep 2013 15:48:54 -0400 > Brett Cannon <brett at python.org> wrote: >>> >>> So I would like to propose the following API change: >>> >>> - Path.stat() (and stat-accessing methods such as getmtime()...) >>> returns an uncached stat object by default >>> >>> - Path.cachestat() can be called to return the stat() and >>> cache it for future use, such that any future call to stat(), >>> cachestat() or a stat-accessing function reuses that cached stat >>> >>> In other words, only if you use cachestat() at least once is the >>> stat() value cached and reused by the Path object. >>> (also, it's a per-Path decision) >>> >> >> Any reason why stat() can't get a keyword-only cached=True argument >> instead? Or have stat() never cache() but statcache() always so >> that people can choose if they want fresh or cached based on API >> and not whether some library happened to make a decision for them? > > 1. Because you also want the helper functions (getmtime(), etc.) to > cache the value too. It's not only about stat(). With the proposed rich stat object the convenience methods living on Path wouldn't result in much added convenience: p.isdir() vs p.stat().isdir()
One reason is that the proposed rich stat object doesn't exist yet :-)
Regards
Antoine.
- Previous message: [Python-Dev] PEP 428: Pathlib -> stat caching
- Next message: [Python-Dev] PEP 428: Pathlib -> stat caching
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]