Expose `_make_key` in `functools.lru_cache` to caller
Previous Thread on Similar Topic: https://mail.python.org/archives/list/python-ideas@python.org/thread/4XXGPXW... Relevant Code: https://github.com/python/cpython/blob/f9433ff/Lib/functools.py#L528 I have been beset by two different scenarios where having some option to modify the input of the `lru_cache` key would be useful. These are simplified versions of said scenarios, but emphasize why I might want this capability. 1. Scoring model on repeated input. def score(model, feature_vector_that_includes_example_id): ... This would be easily memorizable with a key of (model.__hash__(), feature_vector[ID_INDEX]). 2. Multiple user-friendly wrappers around the same complex internal function def _foo(obj, transform_fn): # Some non-trivial logic new_obj = transform_fn(obj) # Some non-trivial logic return new_obj def foo_1(obj): def _transform_1(obj): ... return foo(obj, _transform_1) def foo_2(obj): def _transform_2(obj): ... return foo(obj, _transform_2) For this subset of functions, I know I can safely use (obj, fn.__name__) as a key. This, alongside the "Previous Thread" (wanting to use a subset of arguments for the key) and the comment in the `_make_key` function (https://github.com/python/cpython/blob/f9433ff/Lib/functools.py#L464), indicate that there are other scenarios in which users might want to customize the `_make_key` function. The main drawbacks I see are 1. Very prone to error (see conversation in "Previous Thread") 2. For sufficiently complex `_make_key` functions, the benefit may be obscured by the cost. For instance, casting a `list` to a `tuple` would incur an O(n) cost, which many users may not recognize. I would love to get community feedback before pursuing this idea further.
participants (1)
-
Alec Mori