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
Current Type Checker Behaviors
Carl generously volunteered to write the conformance tests for the change, and they are also included within the PR branch.
Currently, none of the major type checkers fully comply with the spec. Both mypy and pyright are pretty close, but small changes will be required by all type checkers to fully comply.
Controversial Issues
I think we've worked through most of the controversial issues in the discussion phase. One potentially controversial choice is to mandate expansion of know-length tuples, bools, and Enums.
Also, as Carl has pointed out, the current overload evaluation rules depend on non-overload call behaviors that are not currently fully specified. Presumably, we will eventually specify these behaviors as well, and the call evaluation behaviors for overloaded calls will automatically benefit from that additional clarity.
The text was updated successfully, but these errors were encountered:
I'd like to request that the TC consider adoption of a typing spec update that describes various type checking behaviors related to overloads.
TC Sign-off
Links to PR & Discussion
The PR can be found here. The latest draft incorporates feedback from PR reviews and the discussion.
The discussion can be found here.
Current Type Checker Behaviors
Carl generously volunteered to write the conformance tests for the change, and they are also included within the PR branch.
Currently, none of the major type checkers fully comply with the spec. Both mypy and pyright are pretty close, but small changes will be required by all type checkers to fully comply.
Controversial Issues
I think we've worked through most of the controversial issues in the discussion phase. One potentially controversial choice is to mandate expansion of know-length tuples, bools, and Enums.
Also, as Carl has pointed out, the current overload evaluation rules depend on non-overload call behaviors that are not currently fully specified. Presumably, we will eventually specify these behaviors as well, and the call evaluation behaviors for overloaded calls will automatically benefit from that additional clarity.
The text was updated successfully, but these errors were encountered: