(original) (raw)
On Sat, Sep 4, 2010 at 3:28 AM, Stefan Behnel <stefan\_ml@behnel.de> wrote:
I had been thinking that the lru\_cache should be a class (with a dict-like interface), so it can be used explicitly and not just as a decorator. It could provide a wrap() method to be used as a decorator (or implement \_\_call\_\_ to keep the current semantics, but explicit is better than implicit)
widget\_cache = lru\_cache()
widget\_cache\[name\] = widget
@lru\_cache().wrap
def get\_thingy(name):
return something(name)
# get\_thingy.cache is an lru\_cache instance
print(get\_thingy.cache.hits)
I have been using a similar LRU cache class to store items retrieved from a database. In my case, a decorator-paradigm wouldn't work well because I only want to cache a few of the columns from a much larger query, plus there are multiple functions that want to talk to the cache.
What about adding an intermediate namespace called "cache", so that the new operations are available like this:
I had been thinking that the lru\_cache should be a class (with a dict-like interface), so it can be used explicitly and not just as a decorator. It could provide a wrap() method to be used as a decorator (or implement \_\_call\_\_ to keep the current semantics, but explicit is better than implicit)
widget\_cache = lru\_cache()
widget\_cache\[name\] = widget
@lru\_cache().wrap
def get\_thingy(name):
return something(name)
# get\_thingy.cache is an lru\_cache instance
print(get\_thingy.cache.hits)
I have been using a similar LRU cache class to store items retrieved from a database. In my case, a decorator-paradigm wouldn't work well because I only want to cache a few of the columns from a much larger query, plus there are multiple functions that want to talk to the cache.