[Python-Dev] PEP 428: Pathlib -> stat caching (original) (raw)
Philip Jenvey pjenvey at underboss.org
Wed Sep 18 03:10:53 CEST 2013
- Previous message: [Python-Dev] PEP 428: Pathlib -> stat caching
- Next message: [Python-Dev] PEP 428: Pathlib -> stat caching
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Sep 16, 2013, at 1:05 PM, Antoine Pitrou wrote:
On Mon, 16 Sep 2013 15:48:54 -0400 Brett Cannon <brett at python.org> wrote:
So I would like to propose the following API change: - Path.stat() (and stat-accessing methods such as getmtime()...) returns an uncached stat object by default - Path.cachestat() can be called to return the stat() and cache it for future use, such that any future call to stat(), cachestat() or a stat-accessing function reuses that cached stat In other words, only if you use cachestat() 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 statcache() 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 (getmtime(), 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()
Why not move these methods from Path to a rich stat obj and not cache stat results at all? It's easy enough for users to cache them themselves and much more explicit.
-- Philip Jenvey
- Previous message: [Python-Dev] PEP 428: Pathlib -> stat caching
- Next message: [Python-Dev] PEP 428: Pathlib -> stat caching
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]