-
Notifications
You must be signed in to change notification settings - Fork 237
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
Allow unary + in Literal integers #1550
Conversation
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.
Looks good, but it would be good to get an implementation in at least one type checker. It should be trivial, but as a general principle I'd like the spec to only specify behavior that has actually been implemented.
While reviewing the change I was thinking about whether we should specify what +
means. My conclusion is that it's fine to leave it implicit that it means the same thing as it means at runtime.
Implements python/typing#1550 Fixes python#16727 (a trivial bug I found while implementing this feature)
I wrote an implementation for mypy, which was trivial as expected: python/mypy#16729. |
Implements python/typing#1550 Fixes #16727 (a trivial bug I found while implementing this feature)
Oh, one thing I just thought about. Should a type checker explicitly reject redundant unary |
Good point. I'd say any number of |
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.
Looks good to me. I think it's fine to leave the edge case of whether multiple +
/-
are allowed unspecified.
As discussed in https://discuss.python.org/t/signed-values-in-literal-type/39919