-
-
Notifications
You must be signed in to change notification settings - Fork 31.8k
[Enum] Deprecate member.member access with removal in 3.14 #95077
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
Comments
As somebody who hasn't been following |
Performance timings on my system: The codeimport time
import enum
class Color(enum.Enum):
RED = "Red"
BLUE = "Blue"
GREEN = "Green"
RED, BLUE, GREEN = Color
class FastColor:
RED = Color.RED
BLUE = Color.BLUE
GREEN = Color.GREEN
def f():
for _ in range(10000000):
Color.RED
Color.BLUE
Color.GREEN
def g():
for _ in range(10000000):
FastColor.RED
FastColor.BLUE
FastColor.GREEN
def h():
for _ in range(10000000):
RED
BLUE
GREEN
import timeit
print(round(timeit.timeit('f()', number=1, globals=globals()), 2), end=' ')
print(round(timeit.timeit('g()', number=1, globals=globals()), 2), end=' ')
print(round(timeit.timeit('h()', number=1, globals=globals()), 2), end=' \n\n')
The 3.12 timings are with every enum member being accessed via the Out of curiosity I ran the above code with
So updating code to be correct will keep performance to 3.11 levels (or better). |
How are the timings for accessing |
I can only imagine it's due to the work you and others have done. I had already noticed this in the other issue when comparing 3.10/3.11/3.12, and I was able to get another slight boost by storing the member directly in the descriptor and avoiding a dict lookup. |
Some improvement, but I don't think I can take any credit for that (and those timings are not affected by this issue).
|
I can make |
…r access (GH-95083) * issue deprecation warning for member.member access * always store member property in current class * remove __getattr__
Accessing one enum member from another was originally forbidden, but added later to improve performance (but still warned against in the docs). Those performance issues are no longer a problem, and it is now possible to have deprecation warnings in the code to aid in transitioning away from such usage.
The text was updated successfully, but these errors were encountered: