[issue19859] functools.lru_cache keeps objects alive forever

2013-12-04 Thread Radomir Dopieralski
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,

[issue19859] functools.lru_cache keeps objects alive forever

2013-12-04 Thread Radomir Dopieralski
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

[issue19859] functools.lru_cache keeps objects alive forever

2013-12-03 Thread Radomir Dopieralski
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

2013-12-03 Thread Radomir Dopieralski
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

[issue19859] functools.lru_cache keeps objects alive forever

2013-12-03 Thread Radomir Dopieralski
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 <http://bugs.python.

[issue19859] functools.lru_cache keeps objects alive forever

2013-12-02 Thread Radomir Dopieralski
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 o

[issue12086] Tutorial doesn't discourage name mangling

2011-05-17 Thread Radomir Dopieralski
Radomir Dopieralski added the comment: I am reporting this specifically because I just had two independent cases of people who submitted code that had almost all methods name-mangled (within 2 weeks), and who then pointed to that section of the tutorial as justification. I have a hard time

[issue12086] Tutorial doesn't discourage name mangling

2011-05-16 Thread Radomir Dopieralski
Radomir Dopieralski added the comment: "In the unlikely case that you specifically need to avoid name clashes with subclasses, there is limited support..." ;) -- ___ Python tracker <http://bugs.python.o

[issue12086] Tutorial doesn't discourage name mangling

2011-05-16 Thread Radomir Dopieralski
New submission from Radomir Dopieralski : In the tutorial, at http://docs.python.org/tutorial/classes.html#private-variables you can read: 9.6. Private Variables “Private” instance variables that cannot be accessed except from inside an object don’t exist in Python. However, there is a