On Wed, Jul 28, 2010 at 4:50 PM, Gregory P. Smith <greg@krypto.org> wrote:
On Tue, Jul 27, 2010 at 6:43 PM, R. David Murray <rdmurray@bitdance.com> wrote:
On Tue, 27 Jul 2010 08:27:35 +0200, Stefan Behnel <stefan_ml@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 | ncoghlan@gmail.com | Brisbane, Australia