<p dir="ltr"><br>
On 17 Sep 2013 06:45, "Antoine Pitrou" <<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>> wrote:<br>
><br>
> On Mon, 16 Sep 2013 16:14:43 -0400<br>
> "R. David Murray" <<a href="mailto:rdmurray@bitdance.com">rdmurray@bitdance.com</a>> wrote:<br>
> > On Mon, 16 Sep 2013 15:48:54 -0400, Brett Cannon <<a href="mailto:brett@python.org">brett@python.org</a>> wrote:<br>
> > > On Mon, Sep 16, 2013 at 3:45 PM, Antoine Pitrou <<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>> wrote:<br>
> > > > So I would like to propose the following API change:<br>
> > > ><br>
> > > > - Path.stat() (and stat-accessing methods such as get_mtime()...)<br>
> > > >   returns an uncached stat object by default<br>
> > > ><br>
> > > > - Path.cache_stat() can be called to return the stat() *and* cache it<br>
> > > >   for future use, such that any future call to stat(), cache_stat() or<br>
> > > >   a stat-accessing function reuses that cached stat<br>
> > > ><br>
> > > > In other words, only if you use cache_stat() at least once is the<br>
> > > > stat() value cached and reused by the Path object.<br>
> > > > (also, it's a per-Path decision)<br>
> > > ><br>
> > ><br>
> > > Any reason why stat() can't get a keyword-only cached=True argument<br>
> > > instead? Or have stat() never cache() but stat_cache() always so that<br>
> > > people can choose if they want fresh or cached based on API and not whether<br>
> > > some library happened to make a decision for them?<br>
> ><br>
> > Well, we tend to avoid single boolean arguments in favor of differently<br>
> > named functions.<br>
> ><br>
> > But here is an alternate API:  expose the state by having a 'cache_stat'<br>
> > attribute of the Path that is 'False' by default but can be set 'True'.<br>
><br>
> Thanks for the suggestion, that's a possibility too.<br>
><br>
> > It could also (or only?) be set via an optional constructor argument.<br>
><br>
> That's impractical if you get the Path object from a library call.</p>
<p dir="ltr">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.</p>

<p dir="ltr">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.</p>

<p dir="ltr">Cheers,<br>
Nick.</p>
<p dir="ltr">><br>
> Regards<br>
><br>
> Antoine.<br>
><br>
><br>
> _______________________________________________<br>
> Python-Dev mailing list<br>
> <a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/python-dev">https://mail.python.org/mailman/listinfo/python-dev</a><br>
> Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com">https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com</a><br>
</p>