Expose `_make_key` in `functools.lru_cache` to caller
Previous Thread on Similar Topic: https://firstname.lastname@example.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.