For what it's worth, pytype also assumes the definition order matters.
("From narrow to broad", as it says in link Jelle posted.) I'm also very
surprised PEP 484 doesn't describe this behavior, because I'm sure I read
it there before.
-- Teddy
On Thu, Feb 25, 2021 at 7:00 AM Jelle Zijlstra
A few years ago Michael Lee redid much of the overload handling in mypy. His specification is in https://github.com/python/typing/issues/253#issuecomment-389262904; the idea was to eventually turn it into a PEP, but evidently that never happened.
El jue, 25 feb 2021 a las 3:45, Sebastian Rittau (
) escribió: This came up in https://github.com/python/typeshed/pull/5067. In typeshed we have a few places where we assume that overloads are processed in definition order. For example:
``` @overload def foo(x: float) -> int: ... @overload def foo(x: object) -> str: ...
reveal_type(foo(1.3)) # should be "int" ```
mypy warns about this case and must be silenced with "# type: ignore", but accepts it as do the other type checkers to my knowledge. I was surprised that this behavior is not described in either PEP 484 nor the typing docs. What can we do about this?
I see the following options:
- Clarify this behavior only in the typing docs. - Clarify this behavior both in the typing docs and in PEP 484. (My preferred option.) - Write a new PEP. - Do nothing.
(Also I noticed that PEP 484 is still "Provisional".)
- Sebastian
_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: jelle.zijlstra@gmail.com
_______________________________________________ Typing-sig mailing list -- typing-sig@python.org To unsubscribe send an email to typing-sig-leave@python.org https://mail.python.org/mailman3/lists/typing-sig.python.org/ Member address: tsudol@google.com