[issue44310] lru_cache memory leak

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

[issue44310] lru_cache memory leak

Change by Terry J. Reedy : -- versions: -Python 3.6, Python 3.7, Python 3.8 ___ Python tracker ___ ___ Python-bugs-list mailing

[issue44310] lru_cache memory leak

Ken Jin added the comment: @Wouter Hmm, I thought most use cases of lru_cache benefit from strong references for predictable hit rates? I'm not an expert in this area, so I nosied-in someone else who is. However, I noticed that the current doc doesn't mention the strong reference behavior

[issue44310] lru_cache memory leak

Pablo Galindo Salgado added the comment: Using a weak dictionary is not a correct solution as the cache must take string ownership of the arguments and return value to do it's job properly. Moreover, there are many types in Python that don't support weak references so this will be a

[issue44310] lru_cache memory leak

Change by Joannah Nanjekye : -- nosy: +nanjekyejoannah, pablogsal ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue44310] lru_cache memory leak

Change by Roundup Robot : -- keywords: +patch nosy: +python-dev nosy_count: 1.0 -> 2.0 pull_requests: +25122 stage: -> patch review pull_request: https://github.com/python/cpython/pull/26528 ___ Python tracker

[issue44310] lru_cache memory leak

Change by Wouter De Borger : -- type: -> resource usage ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44310] lru_cache memory leak

New submission from Wouter De Borger : # Problem the functools.lru_cache decorator locks all arguments to the function in memory (inclusing self), causing hard to find memory leaks. # Expected I had assumed that the lru_cache would keep weak-references and that when an object is garbage