Strange behaviour for @multi_cached decorator

[alvassin]

When i specify key_builder for @multi_cached decorator, it makes two strange things: it modifies input for target function, and also return modified keys:

import asyncio

from aiocache import multi_cached


def key_builder(key, f, *args, **kwargs):
    return key, args[0]


class MyClass:
    @multi_cached(
        keys_from_attr='ids',
        key_builder=key_builder,
    )
    async def example(self, ids):
        print('example called', ids)
        return {id_: id_ for id_ in ids}


async def main():
    obj = MyClass()
    # {
    #   (1, <__main__.MyClass object at 0x10d1bf490>): (1, <__main__.MyClass object at 0x10d1bf490>),
    #   (2, <__main__.MyClass object at 0x10d1bf490>): (2, <__main__.MyClass object at 0x10d1bf490>)
    # }
    results = await obj.example(ids=[1, 2])
    print(results)


asyncio.run(main())

I expect that this decorator at least should not change input parameters for target function. If i call MyClass().example(ids=[1,2]) i should get ids=[1,2] in my target function.

I also expected that result keys of function MyClass.example(ids=[1,2]) would also be unchanged - it is very confusing that decorator changes function result value. It should just perform caching.

[Dreamsorcerer]

A key should be a string, not a tuple. See the examples:

aiocache/examples/alt_key_builder.py

Lines 62 to 79 in ceb0b5e

	def ensure_no_spaces(key, namespace, replace="_"):
	"""Prefix key with namespace; replace each space with ``replace``"""
	aggregate_key = f"{namespace}{key}"
	custom_key = aggregate_key.replace(' ', replace)
	return custom_key
	def bytes_key(key, namespace):
	"""Prefix key with namespace; convert output to bytes"""
	aggregate_key = f"{namespace}{key}"
	custom_key = aggregate_key.encode()
	return custom_key
	def fixed_key(key, namespace):
	"""Ignore input, generate a fixed key"""
	unchanging_key = "universal key"
	return unchanging_key

v1 will have type annotations etc. that should help make this more obvious.

[alvassin]

@Dreamsorcerer thank you for response. Anyway, even if i make str keys, decorator changes input parameters for target function. It is very confusing.

In my opinion, decorator should not force you to change how do you work with your entities - current implementation requires me to workaround strange keys, that are really needed only for inner cache implementation for this decorator.

I expected decorator is just plug-in and go, and should not change interfaces for my business logic.

I'll write implementation for myself in different package, but just to share: current implementation is very confusing.

[Dreamsorcerer]

Yeah, that doesn't sound right. Can you create a PR with a test reproducing the problem?

[Dreamsorcerer]

Actually, I think this is expected behaviour. It's unique to multi_cached:

aiocache/aiocache/decorators.py

Lines 169 to 187 in ceb0b5e

	Only supports functions that return dict-like structures. This decorator caches each key/value
	of the dict-like object returned by the function. The dict keys of the returned data should
	match the set of keys that are passed to the decorated callable in an iterable object.
	The name of that argument is passed to this decorator via the parameter
	``keys_from_attr``. ``keys_from_attr`` can be the name of a positional or keyword argument.
	If the argument specified by ``keys_from_attr`` is an empty list, the cache will be ignored
	and the function will be called. If only some of the keys in ``keys_from_attr``are cached
	(and ``cache_read`` is True) those values will be fetched from the cache, and only the
	uncached keys will be passed to the callable via the argument specified by ``keys_from_attr``.
	By default, the callable's name and call signature are not incorporated into the cache key,
	so if there is another cached function returning a dict with same keys, those keys will be
	overwritten. To avoid this, use a specific ``namespace`` in each cache decorator or pass a
	``key_builder``.
	If ``key_builder`` is passed, then the values of ``keys_from_attr`` will be transformed
	before requesting them from the cache. Equivalently, the keys in the dict-like mapping
	returned by the decorated callable will be transformed before storing them in the cache.

I'm not too clear on the logic of why this exists...

[Dreamsorcerer]

I think your expectation probably makes sense though. I'm happy to accept a PR changing this behaviour in v1.