On Wed, Jul 28, 2010 at 4:50 PM, Gregory P. Smith <g...@krypto.org> wrote: > On Tue, Jul 27, 2010 at 6:43 PM, R. David Murray <rdmur...@bitdance.com> > wrote: >> On Tue, 27 Jul 2010 08:27:35 +0200, Stefan Behnel <stefan...@behnel.de> >> wrote: >> > Gregory P. Smith, 27.07.2010 07:40: >> > > Random replacement without dropping everything at least means apps >> > > thrashing >> > > the cache degrade much more gracefully. >> > >> > The same algorithm should be helpful in ElementTree's ElementPath >> > module. >> >> We recently added the old re cache-clearing strategy to >> fnmatch, because previously its cache would grow indefinitely. >> It sounds like this should be applied there as well. >> >> That's three...time to figure out how to share the code? > > No doubt.
Anyone remember off the top of their head what linecache does? ... ah, it's just unbounded unless you call clearcache(). Probably OK for that particular application. > Its already a standalone _shrink_cache function with unit tests that doesn't > care the dictionaries it is shrinking are composed of. Easy enough to move > somewhere more useful. Any proposed stdlib locations? I'll be offline on > vacation soon so I may not get to it for a couple weeks but feel free to > move it without me if anyone is interested. I created a tracker issue for the idea so we don't forget about it: http://bugs.python.org/issue9396 collections seems like a fairly obvious possibility, but the flavour doesn't quite seem right for that. Nowhere else springs to mind though. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
