This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author AlexWaygood
Recipients AlexWaygood, DiddiLeija, JelleZijlstra, Spencer Brown, kj, rhettinger, ronaldoussoren, sobolevn
Date 2022-02-22.22:13:23
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1645568003.21.0.52016765866.issue45100@roundup.psfhosted.org>
In-reply-to
Content
I'd dearly like better introspection tools for functions decorated with @overload, but I'd rather have a solution where:

- inspect.signature doesn't have to import typing. That doesn't feel worth it for users who aren't using typing.overload, but inspect.signature would have to import typing whether or not @overload was being used, in order to *check* whether @overload was being used.
- The solution could be reused by, and generalised to, other kinds of functions that have multiple signatures.

If we create an __overloads__ dunder that stored the signatures of multi-signature functions, as Raymond suggests, inspect.signature could check that dunder to examine whether the function is a multi-dispatch signature, and change its representation of the function accordingly. This kind of solution could be easily reused by other parts of the stdlib, like @functools.singledispatch, and by third-party packages such as plum-dispatch, multipledispatch, and Nikita's dry-python/classes library.

So, while it would undoubtedly be more complex to implement, I much prefer Raymond's suggested solution.
History
Date User Action Args
2022-02-22 22:13:23AlexWaygoodsetrecipients: + AlexWaygood, rhettinger, ronaldoussoren, JelleZijlstra, Spencer Brown, sobolevn, kj, DiddiLeija
2022-02-22 22:13:23AlexWaygoodsetmessageid: <1645568003.21.0.52016765866.issue45100@roundup.psfhosted.org>
2022-02-22 22:13:23AlexWaygoodlinkissue45100 messages
2022-02-22 22:13:23AlexWaygoodcreate