You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a function which accepts either 1 positional int argument or any number of str arguments, all passed positionally, and packed into a tuple upon return. I thought I could do this:
This works in a non-overloaded context (reveal_type(f_non_overloaded("a", "b")) should reveal tuple[Literal['a'], Literal['b']] or tuple[str, str], and attempts to pass non-strs should emit typing errors). However, it doesn't work in an overloaded context.
Some quick experiments reveal that
No type-checkers seem to support a union of callables in any overload.
No type-checkers seem to support an overloaded callable in any overload (so a @transform_into_overloaded_callable is either not allowed on an overload item, or does not produce a valid overloaded callable type).
mypy allows nominal types which are callable in an individual overload item (see e.g. mypy Playground). Other type-checkers don't seem to allow this.
(1) also results in confusing error messages across type-checkers; mypy and pyrefly both say something to the effect of
Callable[[*Ts], tuple[*Ts]] | Callable[[*tuple[str, ...]], Never] is not callable
My questions are:
Should nominal types which support __call__ be allowed as the type of an overload item? (My gut feeling says this should be allowed, otherwise someone who wants to use the signature of a nominal type's __call__ will end up having to add a no-op def deco[**P, R](f: Callable[P, R], /) -> Callable[P, R]: return f just to appease type-checkers; pyright and pyrefly currently require this workaround).
Assuming this is just a under-specification with no supporting implementations at the moment, should union callable types and overloaded callable types be allowed as individual overload item types?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I have a function which accepts either 1 positional
int
argument or any number ofstr
arguments, all passed positionally, and packed into a tuple upon return. I thought I could do this:This works in a non-overloaded context (
reveal_type(f_non_overloaded("a", "b"))
should revealtuple[Literal['a'], Literal['b']]
ortuple[str, str]
, and attempts to pass non-str
s should emit typing errors). However, it doesn't work in an overloaded context.Some quick experiments reveal that
@transform_into_overloaded_callable
is either not allowed on an overload item, or does not produce a valid overloaded callable type).(1) also results in confusing error messages across type-checkers; mypy and pyrefly both say something to the effect of
My questions are:
__call__
be allowed as the type of an overload item? (My gut feeling says this should be allowed, otherwise someone who wants to use the signature of a nominal type's__call__
will end up having to add a no-opdef deco[**P, R](f: Callable[P, R], /) -> Callable[P, R]: return f
just to appease type-checkers; pyright and pyrefly currently require this workaround).Beta Was this translation helpful? Give feedback.
All reactions