Repository navigation
singledispatch.register fails for lru_cache decorated functions #132064
Description
Bug report
Function decorated with both @singledispatch.register and @lru_chache fails with a cryptic error message.
EDIT: In python 3.14a6. It works in python 3.9~3.13.
Bug description:
import sys
from functools import lru_cache, singledispatch, wraps
from typing import Any, Callable
def wrapped_lru_cache[T: Callable](maxsize: int = 1024) -> Callable[[T], T]:
def decorator(func: T) -> T:
@wraps(func)
def wrapper(*args: Any, **kwargs: Any) -> Any:
return lru_cache(maxsize=maxsize)(func)(*args, **kwargs)
return wrapper # type: ignore
return decorator
if len(sys.argv) > 1 and sys.argv[1] == "--broken-in-py314":
# does not work in python 3.14+
lru = lru_cache
else:
# workaround
lru = wrapped_lru_cache
@singledispatch
def fun(x: str | tuple) -> int:
raise TypeError(f"Input must be str or tuple not a {type(x)}")
@fun.register
@lru(maxsize=1024) # <- this
def _(x: str) -> int:
return len(x)
@fun.register
def _(x: tuple) -> int:
sum = 0
for e in x:
sum += fun(e)
return sum
if __name__ == "__main__":
print(f"{fun("hello")=}")
print(f"{fun(("hello", "sailor"))=}")python ./singledispatch_mwe.py, but python ./singledispatch_mwe.py --broken-in-py314 produces the following error:
Traceback (most recent call last):
File ".../singledispatch_mwe.py", line 25, in <module>
@fun.register
^^^^^^^^^^^^
File "~/.local/share/uv/python/cpython-3.14.0a6-macos-aarch64-none/lib/python3.14/functools.py", line 963, in register
argname, cls = next(iter(get_type_hints(func, format=Format.FORWARDREF).items()))
In python 3.9~3.13 both of the above work.
CPython versions tested on:
3.9~3.14
Operating systems tested on:
macOS
Activity
lczyk commentedon Apr 4, 2025
See here (PR to my own package) for implemented workaround, tested with tox for py39~py314 on ubuntu, macOS and windows (-latest).
lczyk commentedon Apr 4, 2025
Also, i'd say there are at least two things wrong here:
lru_cacheis not wrapping the function properly or.registeris not picking up the type hints correctly (maybe a fallback to the old behaviour?)picnixz commentedon Apr 4, 2025
@rhettinger Was
singledispatchdesigned to work on LRU-decorated functions?lczyk commentedon Apr 4, 2025
for reference, it worked as far back as i've tested, aka down to 3.9. i do realise it might not have been intended to work though, and so this is not necessarily a feature.
picnixz commentedon Apr 4, 2025
Oh so you mean that it's a 3.14+ issue?
lczyk commentedon Apr 4, 2025
yes! sorry, reading back i was not clear about that 😅 (added an
EDITto the original report to make it clearer.)picnixz commentedon Apr 4, 2025
As it uses
get_type_hints(func, format=Format.FORWARDREF), I'm asking first @JelleZijlstra. I can have a look tomorrow thoughrhettinger commentedon Apr 4, 2025
functools.lru_cachecopies essential attributes from the wrapped function withfunctools.update_wrapper. Its current default tuple of attributes isWRAPPER_ASSIGNMENTS = ('__module__', '__name__', '__qualname__', '__doc__', '__annotate__', '__type_params__'). That tuple was last updated by @JelleZijlstra in 2024. Perhaps it should include__annotations__as well. Also contact @ambv to verify that he expects this to work.JelleZijlstra commentedon Apr 5, 2025
This is indeed a consequence of the implementation of PEP 649/PEP 749, specifically this section: https://peps.python.org/pep-0749/#wrappers-that-provide-annotations .
It is fixable in
_functoolsmodule.cby adding an entry tolru_cache_getsetlistfor__annotations__, providing both a getter and a setter that mirror those for the__annotations__attribute on functions. The setter should unconditionally set__annotations__in the__dict__; the getter should return__annotations__from the__dict__if available, else try to call__annotate__if it's in the dict, and cache the result. Anyone interested in implementing that?rhettinger commentedon Apr 6, 2025
@JelleZijlstra, The lru_cache has a pure python implementation as well. The wrapping of both the pure python version and the C version is done in
functools.pywithupdate_wrapper. So, I don't think a C edit is a complete or correct solution.Can this be fixed for the general case by expanding
WRAPPER_ASSIGNMENTSto include__annotations__? The guidance says, "The annotate and annotations attributes should both be supplied with semantics consistent to those of the wrapped object." So it looks to me like__annotations__should be added back toWRAPPER_ASSIGNMENTS:Looking at the
lru_cachewrapping code in pure python, I don't see any part of the current issue that is specific to thelru_cache. AFAICT, this would happen to any wrapped function.JelleZijlstra commentedon Apr 6, 2025
No, adding
__annotations__to WRAPPER_ASSIGNMENTS would be incorrect because it would immediately force evaluation of the annotations of any wrapped function.JelleZijlstra commentedon Apr 6, 2025
The Python implementation of lru_cache already works on 3.14, so it doesn't need any changes to fix this issue. (To test, take the OP's script, comment out the lines in functools.py that import the C implementation, and run the script.)
rhettinger commentedon Apr 6, 2025
Another possibility is for
singledispatch.registerto follow the suggestion in the docs forupdate_wrapper, "To allow access to the original function for introspection and other purposes (e.g. bypassing a caching decorator such as lru_cache(), this function automatically adds a wrapped attribute to the wrapper that refers to the function being wrapped."Presumably,
lru_cacheisn't the only decorator that was broken by the edit toWRAPPER_ASSIGNMENTS.JelleZijlstra commentedon Apr 7, 2025
I found a better fix for the original issue reported here: #132195. This makes annotationlib use the
__annotate__function if present, even if__annotations__is not also present. This should help not only@lru_cache, but any other decorator that usesupdate_wrapperon a wrapper that is not a Python function.With that fix, it's still the case though that
lru_cache-decorated functions don't have a direct__annotations__attribute when the C version is used:This could impact users who (against recommendations) access
__annotations__directly instead of usingannotationlib.get_annotationsor (in previous Python versions)inspect.get_annotations. To fix it, we could add a dedicated__annotations__descriptor to the C version of functools._lru_cache_wrapper. Is that worth it? I'm not sure.gh-132064: Make annotationlib use __annotate__ if only it is present (#…