Open skirpichev opened 1 year ago
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 :)
@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
:)
@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.
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!
python/cpython#80925 - for positional vs kw or positional Edit: and https://github.com/python/cpython/issues/85294
An example:
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: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