Add the concrete classes to the ColorLike and RectLike type unions.
They are already implied by the other types, but should be added for clarity.
Since they are only type aliases to unions, their variable name is not always given, so what they represent might not be entirely obvious to users.
Bonus: Sort types in ColorLike by how often they are used.
Example mypy error message, before:
$ mypy test.py
test.py:38: error: Incompatible types in assignment (expression has type "float", variable has type "int | str | SequenceLike[int]") [assignment]
test.py:39: error: Incompatible types in assignment (expression has type "int", variable has type "SequenceLike[float] | SequenceLike[SequenceLike[float]] | _HasRectAttribute") [assignment]
After (much more clear!):
$ mypy test.py
test.py:38: error: Incompatible types in assignment (expression has type "float", variable has type "Color | SequenceLike[int] | str | int") [assignment]
test.py:39: error: Incompatible types in assignment (expression has type "int", variable has type "Rect | FRect | SequenceLike[float] | SequenceLike[SequenceLike[float]] | _HasRectAttribute") [assignment]
Note:
typing.py now imports things from pygame. I don't think there is any risk of circular imports though.
Note 2:
The _<Shape>Like type unions in geometry.pyi include their concrete classes already.
Add the concrete classes to the
ColorLike
andRectLike
type unions. They are already implied by the other types, but should be added for clarity.Since they are only type aliases to unions, their variable name is not always given, so what they represent might not be entirely obvious to users.
Bonus: Sort types in
ColorLike
by how often they are used.Example mypy error message, before:
After (much more clear!):
Note:
typing.py
now imports things from pygame. I don't think there is any risk of circular imports though.Note 2: The
_<Shape>Like
type unions ingeometry.pyi
include their concrete classes already.