Le Tue, 17 Sep 2013 18:10:53 -0700, Philip Jenvey <pjen...@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 <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(). > > With the proposed rich stat object the convenience methods living on > Path wouldn't result in much added convenience: > > p.is_dir() vs p.stat().is_dir()
One reason is that the proposed rich stat object doesn't exist yet :-) 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
