On Tue, Dec 2, 2014 at 4:57 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 2 December 2014 at 08:41, Cameron Simpson <cs@zip.com.au> wrote:
> On 01Dec2014 17:34, Constantin Berhard <constantin@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.


Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia
Python-ideas mailing list
Code of Conduct: http://python.org/psf/codeofconduct/

--Guido van Rossum (python.org/~guido)