Wrong Signature for singledispatch'ed functions/methods

[skirpichev]

An example:

$ cat -n spam.py 
     1  from __future__ import annotations
     2  from functools import singledispatch
     3  
     4  @singledispatch
     5  def foo(x: int) -> int:
     6      return x + 1
     7  
     8  @foo.register
     9  def _(x: str) -> str:
    10      return "Hello, " + x
$ python
Python 3.11.1+ (heads/3.11:ba88628808, Jan 14 2023, 08:40:06) [GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import inspect, spam
>>> inspect.signature(spam.foo)
<Signature (x: 'int') -> 'int'>

I would expect here something like <Signature (x: int | str) -> int | str> (i.e. union of types for returned value, same for argument) or an exception.

I'm not sure that the first option is on the table: more accurately this situation fits to case of multiple function signatures (like we have in the stdlib e.g. for the min/max). But the current signature() output is misleading.

UPD: In fact, the Signature must be like <Signature (x: int | str, /) -> int | str>, because:

>>> spam.foo(x=1)
Traceback (most recent call last):
  ...
TypeError: foo requires at least 1 positional argument

Or we can make singledispatch'ed function to be with a positional-only argument iff argument names for different overloaded implementations are different.

PS: Inspired by https://discuss.python.org/t/signatures-a-call-to-action/23580

[AlexWaygood]

There's a similar issue with typing.overload that we discussed in #89263. We got halfway to fixing it (@JelleZijlstra made the signature of @overload'd functions accessible at runtime). But I then volunteered to work on displaying the multiple signatures in the output of help() and inspect.signature(), and unfortunately I never finished the job properly :)

[AlexWaygood]

@arhadthedev I'm removing the "expert-typing" label since this issue isn't really about Python's static typing system (static type checkers make no use of inspect.signature()) or anything in typing.py :)

[skirpichev]

@AlexWaygood, thanks for the reference, clearly I've wrong keywords to search.

Probably, you may consider this as a duplicate. But I think, that the second part of issue (updated text, i.e. POSITIONAL_OR_KEYWORD vs POSITIONAL_ONLY kind of parameter) is not covered by #89263.

[AlexWaygood]

Probably, you may consider this as a duplicate

It wasn't my intent to imply that this was a duplicate; I was just pointing you to an earlier discussion on related themes that I thought you might find interesting!

[skirpichev]

#80925 - for positional vs kw or positional
Edit: and #85294