René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"we should not recommend using functools.cache on methods","articleBody":"# Documentation\r\n\r\nCurrently [the documentation for functools.cached_property](https://docs.python.org/3/library/functools.html#functools.cached_property) recommends stacking `@property` and `@functools.cache` decorators to \"achieve an effect similar to\" `functools.cached_property`. But this omits a critical problem with using `@functools.cache` on instance methods: it is an unbounded cache, and will use `self` as a cache key, so any instance on which this \"cached property\" is ever accessed will be kept alive by the cache forever (unless the cache is manually cleared), and the memory used by these cached instances can grow unboundedly.\r\n\r\nThe [FAQ entry on caching methods](https://docs.python.org/3/faq/programming.html#faq-cache-method-calls) does not recommend (or even mention) `functools.cache`, and it explicitly recommends a bounded `functools.lru_cache` in order to avoid keeping alive all instances indefinitely.\r\n\r\nSpecific proposals:\r\n\r\n1. The `cached_property` documentation should not recommend using `functools.cache` on a method.\r\n2. It also doesn't need to give a full example of using `lru_cache` for a method cache; it can instead just mention the possibility, and link to the FAQ entry for more detailed discussion.\r\n\n\n\u003c!-- gh-linked-prs --\u003e\n### Linked PRs\n* gh-104113\n* gh-104182\n\u003c!-- /gh-linked-prs --\u003e\n","author":{"url":"https://github.com/carljm","@type":"Person","name":"carljm"},"datePublished":"2023-05-03T00:18:15.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":2},"url":"https://github.com/104112/cpython/issues/104112"}