Resolve ... vs EllipsisType asymmetry - #4510
Conversation
|
This pull request has been imported. If you are a Meta employee, you can view this in D115576310. (Because this pull request was imported automatically, there will not be any future comments.) |
|
Diff from mypy_primer, showing the effect of this PR on open source code: xarray (https://github.com/pydata/xarray)
- ERROR xarray/core/dataset.py:8354:24-27: Argument `Collection[Hashable] | EllipsisType` is not assignable to parameter `iterable` with type `Iterable[Hashable]` in function `set.__init__` [bad-argument-type]
- ERROR xarray/core/groupby.py:1049:32-35: Argument `Collection[Hashable] | EllipsisType` is not assignable to parameter `iterable` with type `Iterable[Hashable]` in function `tuple.__new__` [bad-argument-type]
- ERROR xarray/core/utils.py:1025:25-28: Argument `Collection[Hashable] | EllipsisType | tuple[str]` is not assignable to parameter `iterable` with type `Iterable[Hashable]` in function `set.__init__` [bad-argument-type]
- ERROR xarray/core/utils.py:1026:18-21: Argument `Collection[Hashable] | EllipsisType | tuple[str]` is not assignable to parameter `iterable` with type `Iterable[Hashable]` in function `tuple.__new__` [bad-argument-type]
- ERROR xarray/core/utils.py:1064:15-18: Argument `Collection[Hashable] | EllipsisType | set[Hashable]` is not assignable to parameter `iterable` with type `Iterable[Hashable]` in function `set.__init__` [bad-argument-type]
- ERROR xarray/core/utils.py:1122:76-86: `in` is not supported between `Ellipsis` and `EllipsisType` [not-iterable]
- ERROR xarray/core/utils.py:1123:54-57: Argument `Collection[Hashable] | EllipsisType` is not assignable to parameter `iterable` with type `Iterable[Hashable]` in function `set.__init__` [bad-argument-type]
- ERROR xarray/core/utils.py:1129:22-25: Argument `Collection[Hashable] | EllipsisType` is not assignable to parameter `iterable` with type `Iterable[Hashable]` in function `tuple.__new__` [bad-argument-type]
|
|
Thanks for the PR! In the future, would you mind first checking if the issue is already assigned and claiming it if it's free? (Don't worry about this PR, though; it looks like it should be pretty easy for me to reconciliate this with my in-progress work.) |
Ahh, apologies; I'm still not quite used to that... Have claimed one or two properly, but forgot here -- will make sure to do so on the next one! 😅👍 |
Summary
Fixes #4426.
Overview
Python has one ellipsis object that can be written two ways: as literal
..., ortypes.EllipsisType.pyreflyrepresents these with two different internal types, but there's an asymmetry in terms of which can be assigned to which (this is the root cause).Specifically: the value
...is inferred asType::Ellipsis, but atypes.EllipsisTypeannotation is inferred asClassType(EllipsisType), and assignability between the two holds in only one direction.Solution
Add the missing/reverse assignability arm.
Ensure
literal_equalrecognises both representations.Test Plan
Unit test suite was run, and a new test was added.
Was able to remove the error markers from:
test_ellipsis_istest_ellipsis_eqUpdated these tests to use
assert_typeas that validates equivalence, rather than matching substrings of the printed type (as perreveal_type).