`@typing.overload` doesn't preserve function attributes (like `__annotations__`)

[thejcannon]

Bug report

Bug description:

Somewhat of a corner-case, but something like this

import typing

class Foo:
    @typing.overload
    def foo(): ...

    print(foo.__qualname__)

prints _overload_dummy which, yeah OK I think I'm the real dummy here, but also did it need to call me that 😝 ?

(In all seriousness I'm just doing weird things, and hit this and even though I'm doing weird things, Python never stopped me before)

CPython versions tested on:

3.11

Operating systems tested on:

macOS

Linked PRs

• gh-129931: use functools.wraps within overloads #129932

[JelleZijlstra]

You can retrieve the original functions with typing.get_overloads. With standard use of @overload, there's usually no way to get the "dummy" function, because the name gets overwritten with the implementation function. So I think your PR mostly slows things down slightly for little gain.

[mauroia609]

No me escriban nada más por favor El dom, 9 de feb de 2025, 11:37 p. m., Josh Cannon ***@***.***> escribió:

…

Bug report Bug description: Somewhat of a corner-case, but something like this import typing class Foo: @typing.overload def foo(): ... print(foo.__qualname__) prints _overload_dummy which, yeah OK I think I'm the real dummy here, but also did it need to call me that 😝 ? (In all seriousness I'm just doing weird things, and hit this and even though I'm doing weird things, Python never stopped me before) CPython versions tested on: 3.11 Operating systems tested on: macOS — Reply to this email directly, view it on GitHub <#129931>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BOZ34Z5AOO4O4WSN6Q3SV2D2PAGE7AVCNFSM6AAAAABWZQK4PWVHI2DSMVQWIX3LMV43ASLTON2WKOZSHA2DCMJXGQZTOMI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[thejcannon]

(Somewhat of an aside, I was trying to use get_overloads and was getting empty overloads due to #129916)

I agree with you. In the case that led me here, I was doing runtime-valid, but type-invalid(-ish) things (like the toy example).

I think that's what it boils down to. Should we do the thing that's more correct for code that is valid Python, but potentially type-invalid(-ish) (I use -ish, because the toy example isn't necessarily type-invalid (assuming it defined the final undecorated function), but also isn't really expected)

I think both answers are probably acceptable, so it's a matter of taste. (I also know typing gets a bad performance rap, so there's that angle too)

[thejcannon]

The workaround is so something like define my own decorator and if TYPE_CHECKING: my_overload = overload (assuming the typerchecker handles aliases of overload well)

[AlexWaygood]

I agree with @JelleZijlstra here. I'm not really sure I see a practical use case for overloads where this would improve introspection at runtime. The @overload-decorated function isn't usable at runtime (it raises an error if you try to call it), so why should it "pretend" to be the original function that was passed to overload()? Not all static-typing errors are enforced at runtime from the typing module, but this one is, and always has been -- you have to provide a non-overload-decorated version of the function in order to use it at runtime, and that version has to come last (so that it overrides all previous @overload-decorated versions of the function in the namespace it's defined in)

[thejcannon]

(to be pedantic, you don't HAVE to (at least not in the class body). I'm replacing the overloaded function inside of a base class' __init_subclass__, the overloads are to specify the expected argument(s) for reader/caller's sake. Admitting this is likely incriminating, but I like being transparent)

[AlexWaygood]

to be pedantic, you don't HAVE to (at least not in the class body). I'm replacing the overloaded function inside of a base class' __init_subclass__, the overloads are to specify the expected argument(s) for reader/caller's sake.

hrm, this is starting to feel like the XY problem 😄 can you start from the beginning and describe the problem you were trying to solve that led you to doing these things with __init_subclass__?

[thejcannon]

I might have to plead the fifth on that one! 😂

The boiled-down version of it looks something like:

class RESTAPI:
    # (Subclasses optionally support `__truediv__` returning a "child" HTTP API instance,
    # relevant to that API's path

    # (Use `__init_subclass__` to reduce the boilerplate)
    def __init_subclass__(cls):
        if "__truediv__" in cls.__dict__:
            # assert its an overload, or something
            # "generate" the implementation 
            cls.__truediv__ = make_truediv_impl(get_overloads(cls.__truediv__))

...
class SomeAPI(RESTAPI):
    @overload
    def __truediv__(self, other: Literal["path1"]) -> "OtherAPI": ...

class OtherAPI(RESTAPI):
    @overload
    def __truediv__(self, some_id: int) -> "OtherOtherAPI": ...

So the "blessed" way to do this would be to have every subclass define the "real" __truediv__ which just calls make_truediv_impl (note that defining __truediv__ in the base isn't ideal, since not all APIs have child paths). But I'm a zealot for making the code as ergonomic as possible and reducing boilerplate/copy+paste, so here we are 😅

If I silence the typechecker complaining about the lack of un-overloaded function (which is a type-error in my library, but not a type-error for client code), everyone is happy. The code reader reads minimal code, the code caller gets good type hints, and the code writer/maintainer doesn't have to deal with a BUNCH of boilerplate. This feels "Pythonic" in the "nice/magical enough to let you express your intent without having to go through all the hoops".

---

But, I'm also admitting I'm pretty far off on the radar, so we're mostly talking about general "correctness". I'll always dig a way out of whatever hole I've dug myself into 😉

[thejcannon]

(edited to include get_overloads for more transparency)

[sobolevn]

Sorry, but this is not how this function should be used :(

I don't think that we should support this.

[sobolevn]

Thanks for the interesting idea and discussion, but I think that other maintainers agree that this issue should be closed.