Skip to content

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

Merged
merged 4 commits into from
May 21, 2022

Conversation

AlexWaygood
Copy link
Member

@AlexWaygood AlexWaygood commented May 21, 2022

@github-actions

This comment has been minimized.

Copy link
Collaborator

@srittau srittau left a 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.

@AlexWaygood
Copy link
Member Author

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.

@AlexWaygood AlexWaygood requested a review from srittau May 21, 2022 13:45
@github-actions

This comment has been minimized.

@github-actions

This comment has been minimized.

@AlexWaygood
Copy link
Member Author

@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 :)

@AlexWaygood AlexWaygood requested a review from JelleZijlstra May 21, 2022 14:03
@github-actions
Copy link
Contributor

According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉

Copy link
Member

@JelleZijlstra JelleZijlstra left a 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.

@AlexWaygood
Copy link
Member Author

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.

@AlexWaygood AlexWaygood merged commit 76a4bd7 into python:master May 21, 2022
@AlexWaygood AlexWaygood deleted the numeric-unions branch May 21, 2022 14:25
@@ -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]
Copy link
Collaborator

@hauntsaninja hauntsaninja May 21, 2022

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?

Copy link
Member Author

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!

hauntsaninja pushed a commit to hauntsaninja/typeshed that referenced this pull request May 21, 2022
python#7906 (comment)
I felt this better documents how seed is used in practice
hauntsaninja added a commit that referenced this pull request May 21, 2022
#7906 (comment)
I felt this better documents how seed is used in practice

Co-authored-by: hauntsaninja <>
AlexWaygood added a commit that referenced this pull request Nov 14, 2022
… 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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants