Partial caching - better caching control

[brianbruggeman]

I think this may be similar, but possibly more generic to the exception handling issue (#138). I'd really like a way of controlling the caching within the cached code.

The basic idea would be to have the current decorator immediately slurp the cache key and set a flag for that key which could be disabled within the cached code base. At the end of the execution, the cached decorator would check to see if the flag is still set and then cache the results. If the flag is not set, then it wouldn't cache the results.

And sort of a follow-on is that I'd like a way of ultimately resetting or dropping the cache based on an external to the cached code decision. I suspect I could come up with a hack for that by simply re-initializing the cache, but I think I'd prefer it to be a method(s) on the cache itself.

[tkem]

Sorry for the delay... I usually tell people that the decorators are there to make simple use cases easy. If you want to do something more complicated, it's probably better to use the Cache subclasses directly than try to extend the decorators. E.g. by providing your own wrapper function/method that checks for an existing cache item, and if none is found, calls the actual function and depending on return status inserts it into the cache or not.

[brianbruggeman]

So I think what I hear you saying is:

1. I should come up with my own method of wrapping some code to cache it
2. Use the base classes already present in cachetools with the caching solution in (1)

I think if I were to do this, I'd end up with another decorator (let's call it cache2) that probably has an additional field within because I really need control over how the code decides to cache and the current cache decorator won't work well for what I need. But additionally, I would likely need to extend the current cachetool classes with at least one additional cache attribute that holds a flag for whether or not I want to cache the data on this specific cycle.

I'm not really opposed to doing the work for this. I already have the need, and I was going to do just that (I've already started that route). I guess I opened this github request up in more of a question as to whether or not you were interested in a Pull Request to update cachetools. I think the feedback here indicates that you'd rather not add more complexity to the current library. I'm cool with that.

Thanks!

[tkem]

@brianbruggeman Sorry for the late response - you're right, with my limited time at hand, I'd rather not add too much options to the library, especially the decorators.