Existing implementation of lru_cache user_function option supports typed_code argument, but does not support maxsize argument, because when we pass in the user function as a positional argument, it gets assigned to the maxsize parameter, and therefore there is no way to pass the actual maxsize value.

The PR implementation supports both signatures
lru_cache(maxsize=128, typed=False)
lru_cache(user_function, maxsize=128, typed=False)

Two concerns is

1. the method signature (inspect.signature(lru_cache)) is not (maxsize=128, typed=False) anymore, and so it is poor documentation.
2. not good reuse of TypeErrors related to incorrect number of inputs / type of inputs.

update:
ignore concern #1. I used __text_signature__ attribute to reset the inspect signature to something useful

https://github.com/python/cpython/pull/19226/commits/eea367f64d2a83d0987a3f7a155ac015306e960b

Since the current signature allows *maxsize* and *typed* to be either positional or keyword arguments, we couldn't do this cleanly the way dataclasses did.  

The code in the PR is valiant attempt but is way too tricky for my tastes -- we would likely regret going down this path.

You can use lru_cache(maxsize=128, typed=False)(user_function). lru_cache should support a function as an argument on if it is a single positional argument, this is the purpose. So you can write

@lru_cache
def func(...):
    ...

instead of

@lru_cache()
def func(...):
    ...

When you pass maxsize and typed you do not pass a function as an argument of lru_cache, you pass it as an argument of the decorator created by the lru_cache() call.

@lru_cache(maxsize=128, typed=False)
def func(...):
    ...

"lru_cache(maxsize=128, typed=False)(user_function)"

oh ok! I overlooked that you could do this. There isn't really a need then for supporting user_function w/ the maxsize argument in single call.

"The code in the PR is valiant attempt but is way too tricky for my tastes"

Yeah. I think only after looking back at the code after writing it I see it is too convoluted. I guess the code can remain as some artifact to show why not to down this path (unless some convenient way to implement it is introduced in the future).

Thanks for putting some thought into this.

np!