[issue9396] Standardise (and publish?) cache handling in standard library

[Raymond Hettinger]

Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I was thinking about the problem of developers wanting a different cache size than that provided in standard lib modules. 

ISTM that now we've offered caching abilities in functools, a developer can easily add another layer of cache around any API they are interested in.  For example, if someone is using thousands of recurring fnmatch patterns, they can write something like:

   @functools.lfu_cache(maxsize=10000)  # custom fat cache
   def fnmatchcase(*args):
       return fnmatch.fnmatchcase(*args)

IMO, this beats adding caching controls to lots of APIs that should be focused only on their problem domain.  IOW, it is probably not a good idea to add purge() and cache_resize() functions to multiple modules throughout the standard lib.

ISTM, we should just provide basic caching with reasonable space consumption (i.e. not huge) that gives improvements to common use cases (like I've done with the fnmatch and re module) and let programmers with unusual cases add their own caching options rather that be tied into our choice of lru vs lfu or whatnot.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9396>
_______________________________________