Author rhettinger
Recipients eric.araujo, flox, ncoghlan, rhettinger
Date 2010-08-09.05:11:43
SpamBayes Score 1.13526e-07
Marked as misclassified No
Message-id <1281330708.09.0.850231362181.issue9396@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2010-08-09 05:11:48rhettingersetrecipients: + rhettinger, ncoghlan, eric.araujo, flox
2010-08-09 05:11:48rhettingersetmessageid: <1281330708.09.0.850231362181.issue9396@psf.upfronthosting.co.za>
2010-08-09 05:11:46rhettingerlinkissue9396 messages
2010-08-09 05:11:43rhettingercreate