(original) (raw)

On 17 Sep 2013 06:45, "Antoine Pitrou" <solipsis@pitrou.net> wrote:
\>
\> On Mon, 16 Sep 2013 16:14:43 -0400
\> "R. David Murray" <rdmurray@bitdance.com> wrote:
\> > On Mon, 16 Sep 2013 15:48:54 -0400, Brett Cannon <brett@python.org> wrote:
\> > > On Mon, Sep 16, 2013 at 3:45 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
\> > > > 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)
\> > > >
\> > >
\> > > 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 whether
\> > > 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.

Cheers,
Nick.

>
\> Regards
\>
\> Antoine.
\>
\>
\> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
\> Python-Dev mailing list
\> Python-Dev@python.org
\> https://mail.python.org/mailman/listinfo/python-dev
\> Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com