-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Simplify and correct many numeric unions #7906
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Okay, I've deleted the proposed |
This comment has been minimized.
This comment has been minimized.
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 |
According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine with the change. I'm not really a fan of the int/float special case but it's here to stay.
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. |
@@ -68,7 +68,7 @@ class Random(_random.Random): | |||
def __init__(self, x: Any = ...) -> None: ... | |||
# 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This one feels a little worse to me in terms of serving as documentation for random.seed, any objections to noqa?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, feel free to revert and add a noqa
!
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