[Enum] Deprecate member.member access with removal in 3.14 #95077

Activity

1. ethanfurman

   added

   type-featureA feature request or enhancementA feature request or enhancement

   stdlibStandard Library Python modules in the Lib/ directoryStandard Library Python modules in the Lib/ directory

   3.12only security fixesonly security fixes

   on Jul 21, 2022
2. brandtbucher commented on Jul 21, 2022

   

   brandtbucher

   on Jul 21, 2022

   Member

   More actions

   Those performance issues are no longer a problem

   As somebody who hasn't been following enum changes very closely: why is this?
3. ethanfurman commented on Jul 21, 2022

   

   ethanfurman

   on Jul 21, 2022

   MemberAuthor

   More actions

   Performance timings on my system:

   The code

   import 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')

   version	enum	"fast" enum	global enum
   3.9	2.23	0.78	0.41
   3.10	2.68	0.91	0.47
   3.11	2.29	0.72	0.21
   3.12	2.21	0.62	0.14

   The 3.12 timings are with every enum member being accessed via the enum.property descriptor (i.e. no enum members being stored directly in the enum class __dict__).

   Out of curiosity I ran the above code with member.member access, both with and without the deprecation warning:

   warning	no warning
   20.41	4.16

   So updating code to be correct will keep performance to 3.11 levels (or better).
4. JelleZijlstra commented on Jul 21, 2022

   

   JelleZijlstra

   on Jul 21, 2022

   Member

   More actions

   How are the timings for accessing Color.RED.value affected?
5. ethanfurman commented on Jul 21, 2022

   

   ethanfurman

   on Jul 21, 2022

   MemberAuthor

   More actions

   Those performance issues are no longer a problem

   As somebody who hasn't been following enum changes very closely: why is this?

   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.
6. ethanfurman commented on Jul 21, 2022

   

   ethanfurman

   on Jul 21, 2022

   Last edited by ethanfurman

   MemberAuthor

   More actions

   How are the timings for accessing Color.RED.value affected?

   Some improvement, but I don't think I can take any credit for that (and those timings are not affected by this issue).

   version	enum property	simple python descriptor	standard property
   3.9	5.96	4.9	2.11
   3.10	5.64	5.01	2.18
   3.11	3.67	3.46	1.58
   3.12	3.03	2.75	0.78
7. ethanfurman commented on Jul 21, 2022

   

   ethanfurman

   on Jul 21, 2022

   MemberAuthor

   More actions

   I can make .name and .value normal properties (when no member by the same name exists), but when I tried that they stopped being reported by inspect and so also stopped showing up in pydoc.
8. ethanfurman

   added a commit that references this issue on Jul 25, 2022

   gh-95077: [Enum] add code-based deprecation warnings for member.membe…

   ...

   4e704d7
9. ethanfurman

   closed this as not plannedon Apr 18, 2023