[Python-Dev] PEP 428: stat caching undesirable?
ncoghlan at gmail.com
Wed May 1 15:54:10 CEST 2013
On 1 May 2013 22:58, "Charles-François Natali" <cf.natali at gmail.com> wrote:
> > 3) Leave it up to performance critical code, such as the import
> > machinery, or walkdirs that Nick mentioned, to do their own caching, and
> > simplify the filepath API for the simple case.
> > But one can still make life easier for code like that, by adding
> > is_file() and friends on the stat result object as I suggested.
> +1 from me.
> PEP 428 goes in the right direction with a distinction between "pure"
> path and "concrete" path. Pure path support syntactic operations,
> whereas I would expect concrete paths to actually access the file
> system. Having a method like restat() is a hint that something's
> wrong, I'm convinced this will bite some people.
> I'm also be in favor of having a wrapper class around os.stat() result
> which would export utility methods such as is_file()/is_directory()
> and owner/group, etc attributes.
> That way, the default behavior would be correct, and this helper class
> would make it easier for users like walkdir() to implement their own
Walkdir is deliberately built as a decoupled pipeline modelled on os.walk -
the only way it can really benefit from caching without destroying the API
is if the caching is built into the underlying path objects that are then
passed through the pipeline stages.
However, I like the idea of a rich "stat" object, with "path.stat()" and
"path.cached_stat()" accessors on the path objects.
Up to date data by default, easy caching for use cases that need it without
needing to pass the stat data around separately.
> As an added benefit, this would make path objects actually immutable,
> which is always a good thing (simpler, and you get thread-safety for
> Python-Dev mailing list
> Python-Dev at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev