-
-
Notifications
You must be signed in to change notification settings - Fork 1.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
Enum values on enum class can't be reassigned or deleted #7385
Comments
I'll take a look tomorrow, thanks for flagging! |
I assumed that the changes made to
>>> from enum import EnumMeta
>>> EnumMeta.__mro__
(<class 'enum.EnumMeta'>, <class 'type'>, <class 'object'>) The signatures of the overrides that were added in #7231 are identical to the signatures of these methods on Moreover, it seems to me that enum classes require more subtle special casing than can be expressed in the stubs: Python 3.10.2 (tags/v3.10.2:a58ebcc, Jan 17 2022, 14:12:15) [MSC v.1929 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from enum import Enum
>>> class Baz(Enum):
... ONE = 1
...
>>> Baz.TWO = 2
>>> Baz
<enum 'Baz'>
>>> list(Baz)
[<Baz.ONE: 1>]
>>> Baz.TWO
2 There's no runtime exception here; the enumeration simply gains a new class attribute, which is not converted to become a new member. All that said, I'd be fine with this change being reverted if it creates an inconvenience for pyright. Positional-only differences to the runtime aren't that important, and we can always allowlist these two methods if typeshed ever starts using a version of stubtest that has python/mypy#12184 and python/mypy#12203 incorporated. (The two stubtest changesets together would mean that stubtest would start emitting errors for |
I think all type checkers special-case (ignore) the I'd prefer not to add special-case logic to ignore additional |
Fair enough, I wasn't aware! Perhaps we should add a comment to the stub for
Yes, I agree. I'll send a PR to revert the changes to |
It's a different discussion (and probably not worth the disruption to remove them, since they don't seem to be doing any harm and you never know which changes will cause unexpected breakages), but I wonder if there's even any point having |
I think all type checkers (I tested mypy and pyright) allow explicitly calling class Foo: ...
foo = Foo()
foo.__setattr__("hello", 2) # allowed
foo.hello = 2 # not allowed If we want to retain that behavior, then there is utility in retaining those methods on |
The
EnumMeta
class inenum.pyi
was recently modified to include a__setattr__
and__delattr__
method. These were flagged as a bug in pyright's unit tests because an attempt to set or delete an attribute on an enum class results in a runtime error.The above code is no longer flagged as an error by pyright although it generates a runtime exception.
@AlexWaygood, I think you submitted the PR for this change. Was the addition of
__setattr__
and__delattr__
intentional?The text was updated successfully, but these errors were encountered: