You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Support attribute access on enum members correctly (#19422)
Fixes#11368 (apparently canonical).
Fixes#10910.
Fixes#12107.
Fixes#13841.
Fixes#15186.
Fixes#15454.
Fixes#19418.
`mypy` now understands attribute access on enum members - the
"recursive" behaviour of supporting access of almost-all enum members
from members. "Almost", because `.name` and `.value` take precedence
even if a member of the same name exists.
```python
from enum import Enum
class E(Enum):
FOO = 1
BAR = 1
# The following is still a `E.BAR` instance:
E.FOO.FOO.BAR.BAR
```
Looks like this is a much wanted feature.
@@ -1984,14 +1985,16 @@ class A(Enum): # E: Detected enum "lib.A" in a type stub with zero members. The
1984
1985
# N: See https://typing.readthedocs.io/en/latest/spec/enums.html#defining-members
1985
1986
x: int
1986
1987
class B(A):
1987
-
x = 1 # E: Cannot override writable attribute "x" with a final one
1988
+
x = 1 # E: Cannot override writable attribute "x" with a final one \
1989
+
# E: Incompatible types in assignment (expression has type "B", base class "A" defined the type as "int")
1988
1990
1989
1991
class C(Enum):
1990
1992
x = 1
1991
1993
class D(C): # E: Cannot extend enum with existing members: "C" \
1992
1994
# E: Detected enum "lib.D" in a type stub with zero members. There is a chance this is due to a recent change in the semantics of enum membership. If so, use `member = value` to mark an enum member, instead of `member: type` \
1993
1995
# N: See https://typing.readthedocs.io/en/latest/spec/enums.html#defining-members
1994
-
x: int # E: Cannot assign to final name "x"
1996
+
x: int # E: Incompatible types in assignment (expression has type "int", base class "C" defined the type as "C") \
0 commit comments