On Mon, 16 Sep 2013 15:48:54 -0400 Brett Cannon <br...@python.org> 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?
1. Because you also want the helper functions (get_mtime(), etc.) to cache the value too. It's not only about stat(). 2. Because of the reverse use case where you want a library to reuse a cached value despite the library not using an explicit caching call. Basically, the rationale is: 1. Caching should be opt-in, which is what this new API achieves. 2. Once you have asked for caching, most always you also want the subsequent accesses to be cached. I realize there should be a third method clear_cache(), though ;-) 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/archive%40mail-archive.com
