Support attribute access on enum members correctly#19422
Support attribute access on enum members correctly#19422ilevkivskyi merged 3 commits intopython:masterfrom
Conversation
| class B3(A3): | ||
| x = 1 # E: Cannot override final attribute "x" (previously declared in base class "A3") | ||
|
|
||
| x = 1 # E: Cannot override final attribute "x" (previously declared in base class "A3") \ |
There was a problem hiding this comment.
Note that this (and other equivalent) change is correct: as per the spec, unannotated attrs should be interpreted as nonmembers, so, strictly speaking, you're assigning a soon-to-become enum instance to something of type int, breaking the interface. And it doesn't matter much as there is already another diagnostic on this line.
This comment has been minimized.
This comment has been minimized.
sobolevn
left a comment
sobolevn
left a comment
There was a problem hiding this comment.
Thanks, looks reasonable! Not a full review, though.
JukkaL
left a comment
JukkaL
left a comment
There was a problem hiding this comment.
Looks good to me, but I'm probably not the best expert on enum semantics. Let's keep this open for a while in case somebody else would have a detailed look. Nice to see this fix so many issues!
|
Okay, I think this has been collecting dust long enough? @ilevkivskyi there are two green reviews here, please take a look if you have time:) |
|
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅ |
4 participants
Fixes #11368 (apparently canonical).
Fixes #10910.
Fixes #12107.
Fixes #13841.
Fixes #15186.
Fixes #15454.
Fixes #19418.
mypynow understands attribute access on enum members - the "recursive" behaviour of supporting access of almost-all enum members from members. "Almost", because.nameand.valuetake precedence even if a member of the same name exists.Looks like this is a much wanted feature.