On 4 December 2014 at 08:41, Constantin Berhard firstname.lastname@example.org wrote:
On 03.12.2014 23:33, Ethan Furman wrote:
On 12/03/2014 02:24 PM, Constantin Berhard wrote:
On 03.12.2014 22:22, Andrew Barnert wrote:
I need this to make my decorator compatible with lru_cache. https://titania.fs.uni-saarland.de/projects/libtco It's only 27 lines of code, you may read it if you want to understand my problem. (additionally 62 lines of example code)
I think you are missing the point: the internals are not going be made public; you need to write your own custom lru_cache.
I don't need or want an lru_cache. I want people, who want to use my library, to be able to use the standard functools together with my lib. So I want to become compatible with lru_cache.
There are *a lot* of memoisation decorators out there - functools.lru_cache is only one of them. It's highly unlikely *any* of them are going to trigger if the call throws an exception.
However, it looks as if your library will add the appropriate cache entry on the next pass through the iterative loop, so it isn't clear what additional values you would like to cache.
As Ethan suggests, a clearer explanation of the current incompatibility, and what additional cache entries you would like to be able to inject may help us better understand the suggestion.