Simplify and correct many numeric unions - #7906
AlexWaygood merged 4 commits into
Conversation
Sorry, something went wrong.
This comment has been minimized.
There was a problem hiding this comment.
I'm a bit concerned with replacing int | bool with int. While it's of course technically true, it's a bit of a historical accident that bool is a subclass of int. (As bool was not originally in Python.) I'd rather see it stay in cases where foo(123) and foo(True) are different use cases. On the other hand, in the long run we should replace bool | int with just bool in cases, where the argument is used like a boolean (and you started working towards this in this PR by replacing int with Literal[0, 1]).
For example, in urllib3 I think it would make more sense to annotate the retries argument with Retry | int | Literal[False] | None, even if Literal[False] is technically redundant.
I think this differs from float | int -> int in that int is morally (and per PEP 484) a subtype (but not in implementation) while bool is morally not a subtype (while it is in implementation), if that makes sense.
Sorry, something went wrong.
|
Okay, I've deleted the proposed int | bool check from my flake8-pyi PR, and I'll remove the cases where I'm simplifying int | bool to just int in this PR. |
Sorry, something went wrong.
This comment has been minimized.
This comment has been minimized.
|
@JelleZijlstra, just want to check you're okay with this as well? I know you had some Thoughts when I tried to do something similar with bytes/bytearray :) |
Sorry, something went wrong.
|
According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉 |
Sorry, something went wrong.
JelleZijlstra
left a comment
There was a problem hiding this comment.
I'm fine with the change. I'm not really a fan of the int/float special case but it's here to stay.
Sorry, something went wrong.
Neither am I, but yeah, there's no way we're going to change that at this point :/ and I think it's good to be consistent across typeshed about this principle. |
Sorry, something went wrong.
| # Using other `seed` types is deprecated since 3.9 and removed in 3.11 | ||
| if sys.version_info >= (3, 9): | ||
| def seed(self, a: int | float | str | bytes | bytearray | None = ..., version: int = ...) -> None: ... # type: ignore[override] | ||
| def seed(self, a: float | str | bytes | bytearray | None = ..., version: int = ...) -> None: ... # type: ignore[override] |
There was a problem hiding this comment.
This one feels a little worse to me in terms of serving as documentation for random.seed, any objections to noqa?
Sorry, something went wrong.
There was a problem hiding this comment.
No, feel free to revert and add a noqa!
Sorry, something went wrong.
python#7906 (comment) I felt this better documents how seed is used in practice
#7906 (comment) I felt this better documents how seed is used in practice Co-authored-by: hauntsaninja <>
… from #7906 (#9130) * Adapt number types in ast Since mypy 0.990 type promotions was limited. This means that complex is not longer promoted to int/float, therefore we should adapt the types to list all possible types Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com> Co-authored-by: AlexWaygood <alex.waygood@gmail.com>
Unblocks PyCQA/flake8-pyi#222