On Tue, Dec 2, 2014 at 4:57 AM, Nick Coghlan firstname.lastname@example.org wrote:
On 2 December 2014 at 08:41, Cameron Simpson email@example.com wrote:
On 01Dec2014 17:34, Constantin Berhard firstname.lastname@example.org
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 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 | email@example.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Pythonfirstname.lastname@example.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/