-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Fix enum attributes are not members #17207
Fix enum attributes are not members #17207
Conversation
f319685
to
ba435ac
Compare
This comment has been minimized.
This comment has been minimized.
isinstance(sym.node, mypy.nodes.Var) | ||
and name not in ENUM_REMOVED_PROPS | ||
and not name.startswith("__") | ||
and sym.node.has_explicit_value |
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 last condition changes the behavior of mypy which currently considers unassigned but annotated attributes as members of the enum.
I would say the new behavior is better but it must be noted in the PR title or description that this is a breaking change that must be considered on its own.
Looking at the mypy primer output, it looks like members of enums constructed using the enum call syntax do not have the has_explicit_value
set which breaks type narrowing. I suggest changing the variable here to also set this flag perhaps with a comment explaining the reason -- something like "E = Enum("E", "A")
is equivalent to class E(Enum): A = auto()
"
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.
Thanks for noticing that, I've not really used them in that form, but hopefully the comment is not too wordy. I only glanced at the code that you pointed to, but I was cross referencing https://github.com/python/cpython/blob/7528b84e947f727734bd802356e380673553387d/Lib/enum.py#L828-L839 and how much of this is implemented by mypy? 🤔
This comment has been minimized.
This comment has been minimized.
It looks like this is actually related to the ongoing discussion python/typing-council#11 |
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.
Thank you @terencehonles.
The typing spec change has been accepted and this PR looks good to me.
Regarding the mypy primer diff, it is related to the linked typing spec change that requires assignment for enum attributes for them to be considered members of the enumeration and the fact that tanjun vendors an old copy of the stdlib inspect module and stub that relies on the old behavior. So the new errors are expected.
This adds on to the change in python#17182 and fixes enum attributes being used as members.
5383c49
to
dfcc0c4
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
@hamdanal sorry for the delay getting back to this, I went on vacation and then coming back was pretty busy. Work's on break for the week so I figured I could pick this up to keep it from getting delayed any further. I was having trouble forcing mypy to not use the explicitly provided annotation for an enum member and I will probably have to leave it at this. I left a comment https://github.com/python/mypy/pull/17207/files#diff-8b48b1eca587106e3806bfa9e14b7f7f344e117b203ffc716ce6fef7f2e68fe6R1610 about the test that was added for #11971. The code in question will need to ignore this new error, but as mypy better supports enums the code will need to change as it seems like it's abusing enums a bit. |
This comment has been minimized.
This comment has been minimized.
This change removes the type attributes on WebsocketNotification which will become errors as of python/mypy#17207 see: https://typing.readthedocs.io/en/latest/spec/enums.html#defining-members:~:text=Members%20defined%20within%20an%20enum%20class%20should%20not%20include%20explicit%20type%20annotations.
@hamdanal / @JelleZijlstra friendly ping if you have a chance to look over the PR or suggestions on how to fix ^^^ |
This comment has been minimized.
This comment has been minimized.
@hamdanal / @JelleZijlstra friendly ping |
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.
LGTM, thanks.
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.
Thanks! This change brings mypy closer in line with the new typing spec chapter on enums
I'm confused by the primer hits on Tanjun |
This comment has been minimized.
This comment has been minimized.
I looked a little and couldn't figure out what's going on there either. Both cases involve narrowing an enum attribute inside a loop. I wasn't able to reproduce a similar error with a simple test case, or even by cloning Tanjun and running mypy from this PR directly on those files. |
I wasn't able to repro minimised, but I can repro locally via |
Oh wait, it vendors inspect |
This is the regression:
|
@hauntsaninja I believe this might be related to my comment:
But this seems to also not be warning about the: class _ParameterKind(enum.IntEnum):
POSITIONAL_ONLY: int
POSITIONAL_OR_KEYWORD: int
VAR_POSITIONAL: int
KEYWORD_ONLY: int
VAR_KEYWORD: int and I can minimally reproduce with:
So maybe it's actually that? If I add a |
This comment has been minimized.
This comment has been minimized.
…er which is also the base of all types
@hauntsaninja I got to the bottom of it, and I fixed it in a way that I figured would have the least amount of knock on effects. According to the spec The issue though is that |
Actually I think if there was a warning if an expression is always true or always false, then this should be removed since the way I implemented things is that it hides |
Diff from mypy_primer, showing the effect of this PR on open source code: pytest (https://github.com/pytest-dev/pytest)
+ src/_pytest/scope.py:36: error: Enum members must be left unannotated [misc]
+ src/_pytest/scope.py:36: note: See https://typing.readthedocs.io/en/latest/spec/enums.html#defining-members
+ src/_pytest/scope.py:37: error: Enum members must be left unannotated [misc]
+ src/_pytest/scope.py:37: note: See https://typing.readthedocs.io/en/latest/spec/enums.html#defining-members
+ src/_pytest/scope.py:38: error: Enum members must be left unannotated [misc]
+ src/_pytest/scope.py:38: note: See https://typing.readthedocs.io/en/latest/spec/enums.html#defining-members
+ src/_pytest/scope.py:39: error: Enum members must be left unannotated [misc]
+ src/_pytest/scope.py:39: note: See https://typing.readthedocs.io/en/latest/spec/enums.html#defining-members
+ src/_pytest/scope.py:40: error: Enum members must be left unannotated [misc]
+ src/_pytest/scope.py:40: note: See https://typing.readthedocs.io/en/latest/spec/enums.html#defining-members
jax (https://github.com/google/jax)
+ jaxlib/cpu/_lapack/eig.pyi:20: error: Enum members must be left unannotated [misc]
+ jaxlib/cpu/_lapack/eig.pyi:20: note: See https://typing.readthedocs.io/en/latest/spec/enums.html#defining-members
+ jaxlib/cpu/_lapack/eig.pyi:21: error: Enum members must be left unannotated [misc]
+ jaxlib/cpu/_lapack/eig.pyi:21: note: See https://typing.readthedocs.io/en/latest/spec/enums.html#defining-members
|
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.
Thanks, the fix looks great!
I think it might be worth issuing a warning for enums with no members, but only in type stubs. I'll make a PR for that.
This adds on to the change in #17182 and fixes enum attributes being used as members.
@hamdanal / @hauntsaninja I noticed there was the function
get_enum_values
in mypy types and instead of adding more to the case intry_expanding_sum_type_to_union
it seemed like it might make sense to move the changes from #17182 there. I don't think the other code touched in that PR can useget_enum_values
.fixes: #16730