On Thu, Apr 30, 2009 at 7:37 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
George Sakkis <george.sakkis@gmail.com> writes:
I think It's clear by now that caching in the general case is not trivial, both in terms of API and implementation. That makes the original request - caching properties only - more appealing since most problems go away if there are no parameters.
Nevertheless, the “memoize” pattern *is* well-understood, and already implemented for Python as discussed earlier. It covers the “cached property” as a degenerate (i.e. simpler) case. Making a specific decorator that *only* addresses “cached property” is too narrow, IMO.
I think a “memoize” decorator (by whatever name) is the right level of generality to address this use case, and has the advantage of existing implementations.
IMHO no existing implementation is good enough for addition to the standard library. Off the top of my head, some of the issues a general and robust implementation should address are: - Non hashable parameters. - Caching keys based on a subset of the provided parameters (or perhaps more general a key function). - Bounded-length caches. - Different expiration policies for bounded-length caches. - As good performance as possible given the previous constraints. Of course one can write a vanilla version in a few lines, and indeed searching for "memoize" in code.activestate.com returns no less than 125 results (including one I posted 4.5 years ago). I think the sheer number of the posted recipes is an indication that none of them has "solved" the problem for good, otherwise people would just reuse it instead of keep posting alternatives. George