[issue19859] functools.lru_cache keeps objects alive forever

Raymond Hettinger added the comment: I'm not in favor of filling the docs with warnings like this. It tends to make everything sound dangerous even when the tools are doing exactly what they are supposed to do. Every container (except for the weakref containers) keeps their references alive.

[issue19859] functools.lru_cache keeps objects alive forever

Antoine Pitrou added the comment: Just adding a note in the documentation sounds enough. -- nosy: +pitrou ___ Python tracker ___ ___ P

[issue19859] functools.lru_cache keeps objects alive forever

Radomir Dopieralski added the comment: > Umm, that's part of the operational definition of a value based cache > - it needs to keep things alive, so that if a different instance shows > up with the same value, it will still get a cache hit. If it only kept the return value alive, that wouldn't b

[issue19859] functools.lru_cache keeps objects alive forever

Nick Coghlan added the comment: On 4 December 2013 20:15, Radomir Dopieralski wrote: > But I think it's would be still worthwhile to add a note to the lru_cache's > documentation, saying something like: > > """ > Warning! lru_cache will keep references to all the arguments for which it > keeps

[issue19859] functools.lru_cache keeps objects alive forever

Radomir Dopieralski added the comment: Thank you for your attention. I'm actually quite happy with the solution we have, it works well. That's actually I thought that it may be worthwhile to try and push it upstream to Python. I can totally understand why you don't want to add too much to the

[issue19859] functools.lru_cache keeps objects alive forever

Raymond Hettinger added the comment: > Limiting the cache size is also not a solution in the > practical example with request that I linked to in the > previous comment, because we can't know in advance how > many times per request the function is going to be called, > picking an arbitrary numb

[issue19859] functools.lru_cache keeps objects alive forever

Radomir Dopieralski added the comment: Actually, after looking closer, my @memoize_method decorator does something completely different than Serhiy suggested. Still it only solves the common case of methods, and does nothing if you pass your short-lived objects as other parameters than self.

[issue19859] functools.lru_cache keeps objects alive forever

Radomir Dopieralski added the comment: The method example is just the most common case where this problem can be easily seen, but not the only one. We indeed use the @cached_property decorator on properties (similar to https://github.com/mitsuhiko/werkzeug/blob/master/werkzeug/utils.py#L35), a

[issue19859] functools.lru_cache keeps objects alive forever

Raymond Hettinger added the comment: I don't think this is an appropriate use of an LRU cache. There are other ways to "freeze" a method return value (typically by storing the result in an instance). Here's one way of doing it (taken from the source code for Itty https://pypi.python.org/pypi

[issue19859] functools.lru_cache keeps objects alive forever

Serhiy Storchaka added the comment: Perhaps following technique can be used to prevent object's life prolongation: def spam(self, *args, **kwargs): @lru_cache(maxsize=20) def spam(foo, bar=1, *, baz=None): ... self.spam = spam return self.spam(*args, **kwargs) --

[issue19859] functools.lru_cache keeps objects alive forever

Changes by Raymond Hettinger : -- type: resource usage -> enhancement versions: -Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker ___ __

[issue19859] functools.lru_cache keeps objects alive forever

Serhiy Storchaka added the comment: Weak references make no sense in most cases when arguments disappear just after function call. For the self argument of a method it makes more sense. Perhaps lru_cache can return not a function, but a descriptor. This will allow implement special processing

[issue19859] functools.lru_cache keeps objects alive forever

Changes by Raymond Hettinger : -- assignee: -> rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http

[issue19859] functools.lru_cache keeps objects alive forever

Changes by Serhiy Storchaka : -- nosy: +ncoghlan, rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: ht

[issue19859] functools.lru_cache keeps objects alive forever

Changes by Serhiy Storchaka : -- keywords: +patch Added file: http://bugs.python.org/file32950/66c1c9f32567.diff ___ Python tracker ___ __

[issue19859] functools.lru_cache keeps objects alive forever

Radomir Dopieralski added the comment: I prepared a proof of concept solution at: https://bitbucket.org/thesheep/cpython-lru_cache-weakref/commits/66c1c9f3256785552224ca177ed77a8312de6bb8 -- hgrepos: +215 ___ Python tracker

[issue19859] functools.lru_cache keeps objects alive forever

Changes by Antoine Pitrou : -- nosy: +serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://

[issue19859] functools.lru_cache keeps objects alive forever

New submission from Radomir Dopieralski: As most naïve "memoized" decorator implementations, lru_cache keeps references to all the values of arguments of the decorated function in the cache. That means, that if we call such a decorated function with an object as a parameter, that object will b