[Python-Dev] PEP 428: Pathlib -> stat caching
ncoghlan at gmail.com
Tue Sep 17 01:15:26 CEST 2013
On 17 Sep 2013 06:45, "Antoine Pitrou" <solipsis at pitrou.net> wrote:
> On Mon, 16 Sep 2013 16:14:43 -0400
> "R. David Murray" <rdmurray at bitdance.com> wrote:
> > On Mon, 16 Sep 2013 15:48:54 -0400, Brett Cannon <brett at python.org>
> > > On Mon, Sep 16, 2013 at 3:45 PM, Antoine Pitrou <solipsis at pitrou.net>
> > > > 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
> > > > for future use, such that any future call to stat(), cache_stat()
> > > > 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)
> > > >
> > >
> > > Any reason why stat() can't get a keyword-only cached=True argument
> > > instead? Or have stat() never cache() but stat_cache() always so that
> > > people can choose if they want fresh or cached based on API and not
> > > some library happened to make a decision for them?
> > Well, we tend to avoid single boolean arguments in favor of differently
> > named functions.
> > But here is an alternate API: expose the state by having a 'cache_stat'
> > attribute of the Path that is 'False' by default but can be set 'True'.
> Thanks for the suggestion, that's a possibility too.
> > It could also (or only?) be set via an optional constructor argument.
> That's impractical if you get the Path object from a library call.
Given that this is a behavioural state change, I think asking for a
possibly *new* path with caching enabled in that case would be a good way
to go. If we treat path objects as effectively immutable (aside from the
optional internal stat cache), then checking in __new__ if a passed in path
object already has the appropriate caching status and returning it directly
if so, but otherwise creating a new path object with the cache setting
changed would avoid having libraries potentially alter the behaviour of
applications' path objects and vice-versa.
In effect, the unique "identity" of a path would be a triple representing
the type, the filesystem path and whether or not it cached stat results
internally. If you wanted to change any of those, you would have to create
a new object.
> Python-Dev mailing list
> Python-Dev at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev