<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Dec 2, 2014 at 4:57 AM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 2 December 2014 at 08:41, Cameron Simpson <<a href="mailto:cs@zip.com.au">cs@zip.com.au</a>> wrote:<br>
> On 01Dec2014 17:34, Constantin Berhard <<a href="mailto:constantin@exxxtremesys.lu">constantin@exxxtremesys.lu</a>> wrote:<br>
> In fact, I'd advocate moving the LRU cache supporting object off into<br>
> collections and building functools.lru_cache on top of that. Use case: I had<br>
> to write my own LRU cache bcause I wasn't just wrapping a function. Having<br>
> that available as a standalone object from collections which looked like a<br>
> lossy mapping (i.e.  things vanish from the mapping when the cache<br>
> overflows) would be immensely useful.<br>
<br>
</div></div>As far as I'm aware, this is actually a deliberate design decision.<br>
There are so many degrees of freedom in designing a cache API that<br>
without constrainting the usage model it's really quite difficult to<br>
come up with a flexible abstraction that's easier to use than just<br>
building your own custom caching class.<br>
<br>
And once you expose the underlying mapping in functools.lru_cache<br>
itself, it hugely constraints the internal implementation of that<br>
cache (since you just made a whole lot of things that are currently<br>
implementation details part of the public API).<br>
<br>
So collections.OrderedDict provides the raw building block needed to<br>
implement an LRU cache, while functools.lru_cache applies that<br>
building block to a particular use case.<br></blockquote><div><br></div><div>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?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It's OK if folks with needs that don't quite fit the standard idiom<br>
write their own custom class to handle it - that makes it possible to<br>
keep the standard tools simple to handle the standard cases, while<br>
folks with different needs can just write something specifically<br>
tailored to their situation, rather than trying to learn and configure<br>
a more generic API.<br>
<br>
Cheers,<br>
Nick.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" target="_blank">http://python.org/psf/codeofconduct/</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido">python.org/~guido</a>)</div>
</div></div>