-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
Narrow types after 'in' operator. #4071
Comments
I think this can also fall out of #4063 (just as a note; of course a dedicated PR is more practical) |
Careful. For unconstrained x, after x in (1, 2), x may still be a float.
(Or a fraction or decimal?)
…On Oct 8, 2017 6:15 AM, "Elazar Gershuni" ***@***.***> wrote:
I think this can also fall out of #4063
<#4063> (just as a note; of course a
dedicated PR is more practical)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#4071 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ACwrMifVTAK8FQdpXnhnADA9IBWzQ_7jks5sqMr8gaJpZM4PxpHz>
.
|
OK, makes sense, we should not narrow down if we start from |
@gvanrossum OK, I updated PR #4072 x: Any
if x in [1, 2, 3]:
reveal_type(x) # Revealed type is 'Any'
y: float
if y in [1, 2, 3]:
reveal_type(x) # Revealed type is 'builtins.float' It is however not easy to prohibit this: z: object
if z in [1, 2, 3]:
reveal_type(z) # Revealed type is 'builtins.int' This is still formally speaking unsafe, but I think it is a reasonable price to pay. |
Sometimes it is useful to narrow down a type after an
in
/not in
comparison. For example:This seems to be especially useful for
--strict-optional
, for example:(related #2980)
A similar idea was discussed in #1749, but emitting an error on
if 'a' in [1, 2, 3]: ...
would require a larger change: emitting errors on unreachable code in binder.The text was updated successfully, but these errors were encountered: