Repository navigation
functools.singledispatch registration prioritizes the types of normal arguments before positional-only ones #143886
Description
Bug report
Bug description:
Decorator-based functools.singledispatch registration prioritizes the types of normal arguments before positional-only ones when getting "the type of the first argument".
This means that a function of def f(pos: str, /, other: int) will be registered to be dispatched for other's type (int) instead of pos (str).
To reproduce:
import functools
@functools.singledispatch
def f(arg, /, extra):
return f"{arg}: undispatched type"
@f.register
def f_int(arg: int, /, extra: str):
return f"{arg} is a {type(arg)} (dispatched by int)"
@f.register
def f_str(arg: str, /, extra: int):
return f"{arg} is a {type(arg)} (dispatched by str)"
print(f(None, "extra"))
print(f(1, "extra"))
print(f("s", "extra"))Result:
None: undispatched type
1 is a <class 'int'> (dispatched by str)
s is a <class 'str'> (dispatched by int)
Expected:
None: undispatched type
1 is a <class 'int'> (dispatched by int)
s is a <class 'str'> (dispatched by str)
CPython versions tested on:
3.9, 3.10, 3.11, 3.12, 3.13, 3.14, CPython main branch
Operating systems tested on:
macOS
Activity
JelleZijlstra commentedon Jan 15, 2026
That's a good catch! I think #84644 should fix this too.
Your fix is good but the trouble is that it changed compiled code, so compiled pycs won't see the fix, unless we bump the magic number. And we don't generally want to bump the magic number in bugfix releases.
pR0Ps commentedon Jan 15, 2026
You're right, #84644 looks like it should fix function registrations with positional-only args. Since it changes it to no longer rely on the order of hints returned from
typing.get_type_hints, them being out of order wouldn't matter anymore.I still think that the order that
get_type_hintsreturns should be fixed so that it matches how the arguments are defined, but like you said, maybe that can wait until the next non-bugfix release.pR0Ps commentedon Apr 14, 2026
What's the process for fixing something like this? Can it be merged at any point and only after the next magic number bump take effect? Or would merging it and bumping the number need to be done in the same PR?
JelleZijlstra commentedon Apr 15, 2026
We don't bump the magic number in bugfix branches. I think your fix is good for the long term and if you get CI green I will merge it, but we can't apply that change in 3.14 and 3.13; for that we need some version of #143465.
gh-143886: Ensure function annotations are returned in order of defin…
pythongh-143886: Ensure function annotations are returned in order of…
pR0Ps commentedon Oct 16, 2026
@JelleZijlstra Should this be closed now that #143888 has been released in 3.15? Or should it stay open until #143465 can be merged and backported to 3.14?