[Python-ideas] functools.lru_cache manual cache modification

[Guido van Rossum]

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>
> wrote:
> > 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
> had
> > to write my own LRU cache bcause I wasn't just wrapping a function.
> Having
> > that available as a standalone object from collections which looked like
> a
> > 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
missing?


> 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.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20141202/d068d508/attachment-0001.html>