Thomas Kemmer

First of all, thanks for your interest and for providing detailed analysis and explanation for what you are trying to achieve. I very much appreciate that, especially from a first-time...

On a side note, I've learned myself that many maintainers prefer PRs which consist of a single commit, to keep their git log short and clean. Rebasing and squashing is...

@northyorkshire: You should be able to see the review comments now, sorry for the confusion. And yes, I already started some long-postponed (and in retrospect somewhat ill-fated) refactoring when your...

@northyorkshire: Thanks for explaining your use case - it's always informative to learn how this is being used. Regarding integration of key-level locking in the decorators, however, I'm still somewhat...

I also toyed a little with your example code, thinking about how this could be solved _without_ any changes to `cachetools` itself. I came up with a different decorator, which...

Another, much simpler solution that comes to mind would be to somehow pre-seed the cache with the next date _before_ that data is being requested. If that's predictable in some...

> Are you intending to keep func.py? I can see that some of the files have been re-added Yes, for the forseeable future `cachetools.func` will stay as it is. As...

@northyorkshire Sorry for the delay... Due to the added complexity and runtime overhead for simple uses (e.g. the `fib()` example from the README) I'm somewhat reluctant to include this, at...

`cache_clear` (and other operations on the actual cache object) can already be performed by assigning the cache to a variable, as shown in https://cachetools.readthedocs.io/en/latest/#cachetools.cached I agree that a proper `cache_clear`...

I'll be thinking about this, but don't expect anything soon...