functools.singledispatch registration prioritizes the types of normal arguments before positional-only ones

[pR0Ps]

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

Linked PRs

• gh-143886: Ensure function annotations are returned in order of definition #143888
• gh-84644: Fix singledispatch annotation parsing #143465

[JelleZijlstra]

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]

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_hints returns 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]

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.

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]

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.