Raymond Hettinger <[email protected]> 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 <[email protected]>
<http://bugs.python.org/issue9396>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
