Cache key based on "self" in @cached decorator might not always be unique

[joakimnordling]

I found out the hard way that the default behaviour of get_cache_key (or well actually _key_from_args) in the cached decorator is a bit dangerous when using it on a method of a class. By default it converts args to a string, thus rendering self to something like <foo.bar.Baz object at 0x120e9a070> as part of the cache key.

In most cases this is likely not going to cause any issues, but we were actually in our unit tests creating a lot of instances of the class and calling the method with no arguments. Our tests got random failures and in the end I was able to track it down to being caused by the fact that the same memory address was once in a while reused for a new instance and thus old, cached data from the previous <foo.bar.Baz object at 0x120e9a070> was returned by the decorator instead of the cache being empty for the new instance that happened to be in the same memory address.

For now I was able to get around the issue by adding a dummy uuid to each instance and creating a custom key_builder function that uses that uuid to ensure the cache is indeed unique to each instance (current or past).

If you can figure out some way of ensuring the cache would generate the key in a safer way, it'd be highly appreciated. Also adding some sort of disclaimer of the current behaviour to the README or to the documentation of the noself parameter would be nice in lack of a proper fix.

[Dreamsorcerer]

Duplicate #641.