<div dir="ltr">Actually several of these "caches" aren't caches at all -- deleting data from them will break APIs. This is true at least for copyreg, the ABC registry (though the things with cache in their names in ABC *are* proper caches), and the mime types registry. Also urllib.request.urlcleanup() removes the opener set by the install_opener() API.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 1, 2015 at 8:29 AM, Skip Montanaro <span dir="ltr"><<a href="mailto:skip.montanaro@gmail.com" target="_blank">skip.montanaro@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The other elephant might be...<br>
<br>
If your caches can grow without bound so that programmers need to know<br>
about them (so they can clear them, in testing or other situations),<br>
then maybe they aren't well-designed. If cache growth is an issue, I'd<br>
rather see an abstract API for LRU (and other) cache types which<br>
intelligently cap cache size. I suspect that long before you hit the<br>
inevitable MemoryError, unbounded caches probably destroy program<br>
performance by causing large-scale swapping.<br>
<span class="HOEnZb"><font color="#888888"><br>
Skip<br>
</font></span></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>