[Python-ideas] functools.lru_cache manual cache modification
Guido van Rossum
guido at python.org
Tue Dec 2 18:39:17 CET 2014
On Tue, Dec 2, 2014 at 4:57 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 2 December 2014 at 08:41, Cameron Simpson <cs at zip.com.au> wrote:
> > On 01Dec2014 17:34, Constantin Berhard <constantin at exxxtremesys.lu>
> > In fact, I'd advocate moving the LRU cache supporting object off into
> > collections and building functools.lru_cache on top of that. Use case: I
> > to write my own LRU cache bcause I wasn't just wrapping a function.
> > that available as a standalone object from collections which looked like
> > lossy mapping (i.e. things vanish from the mapping when the cache
> > overflows) would be immensely useful.
> As far as I'm aware, this is actually a deliberate design decision.
> There are so many degrees of freedom in designing a cache API that
> without constrainting the usage model it's really quite difficult to
> come up with a flexible abstraction that's easier to use than just
> building your own custom caching class.
> And once you expose the underlying mapping in functools.lru_cache
> itself, it hugely constraints the internal implementation of that
> cache (since you just made a whole lot of things that are currently
> implementation details part of the public API).
> So collections.OrderedDict provides the raw building block needed to
> implement an LRU cache, while functools.lru_cache applies that
> building block to a particular use case.
But, oddly enough, functools.lru_cache doesn't use collections.OrderedDict
-- it uses its own linked list, which strikes me as slow. Or what am I
> It's OK if folks with needs that don't quite fit the standard idiom
> write their own custom class to handle it - that makes it possible to
> keep the standard tools simple to handle the standard cases, while
> folks with different needs can just write something specifically
> tailored to their situation, rather than trying to learn and configure
> a more generic API.
> Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
> Python-ideas mailing list
> Python-ideas at python.org
> Code of Conduct: http://python.org/psf/codeofconduct/
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas