Enum + new in 3.11

[Thomas Passin]

On 6/16/2023 7:37 PM, dn via Python-list wrote:
> On 16/06/2023 23.47, Thomas Passin via Python-list wrote:
>> On 6/16/2023 1:40 AM, dn via Python-list wrote:
>>> Have you figured-out a use for the @enum.member and @enum.nonmember 
>>> decorators (new in Python 3.11)?
>>>
>>>
>> mypy is having trouble with 3.11 enums:
>>
>> "There are 83 open Enum mypy issues at the the time of this writing.
>>
>> Getting the Enum datatype to work with mypy is becoming impossible as 
>> I find myself having to use cast() in at least every other line."
>>
>> (see https://gi
> 
> thub.com/python/mypy/issues/12841)
>>
>> There have also been other changes to enum  in 3.11 - here is a useful 
>> rundown:
>>
>> https://www.andy-pearce.com/blog/posts/2023/Jan/whats-new-in-python-311-new-and-improved-modules/#enum
>>
>> I had no idea....
> 
> 
> Sorry to hear about mypy. PyCharm has its own mechanism - if there's 
> something like mypy underneath, I don't know [which].
> 
> TBH I haven't noticed any such difficulties, BUT haven't tried using 
> more than a defined sub-class of Enum - and using such as a class. Thus:
> 
> class MenuOptions( Enum ):
>      """ Legal menu-choices. """
>      N = "NewGame"
>      L = "LoadGame"
>      ....
> 
> 
> if __name__ == "__main__":
>      n:MenuOptions = MenuOptions.N
>      print( n, type( n ) )
>      # MenuOptions.N <enum 'MenuOptions'>
> 
> works correctly, but strikes me as pedantry.
> (any (mypy) problematic code you'd like me to try (in PyCharm) as a 
> comparison? Perhaps off-list - could summarise any pertinent discoveries 
> later...)
> 
> 
> I tried messing with the enum-members, eg N:str; but realised that 
> although this worked/was passed silently, the name of a member is not 
> actually a string anyway. So, backed that out.
> 
> 
> Had noted the first web.ref but deemed it unimportant (to me - as 
> above). The second I had not found, and enjoyed reading (many thanks!).
> 
> «I’ll be honest, I struggled to think of concrete cases where this would 
> be useful, since I don’t tend to pile additional functionality into my 
> enumerations — they’re almost always just bare classes which are members 
> of another class or module which provides the related functionality. But 
> I think it’s good to broaden your horizons...»
> 
> The last being the same view as led me to this point, and the first, the 
> motivation for this post! As said, I tend to only use enums in a fairly 
> mechanistic fashion.
> 
> However, I have been playing-around with his "additional functionality". 
> For example, adding the idea of a default-value if an enquiry attempts 
> to use a 'key' which is not present (which seems 'natural', but equally 
> goes against (my understanding of) the ethos of an enum). Next, (see 
> earlier comment about having to invoke the @member-target as a function) 
> was the idea that if one is using an enum as a collection of the correct 
> choices/responses in a menu (per code snippet), making the member.value 
> into a function* attempts to reproduce the idiom of using a dict[ionary] 
> to simulate a case/select construct - which combines the idea of an 
> API's constants with making a decision as to which functionality should 
> be invoked.
> 
> * function here (cf "method") because unlikely to locate such 
> functionality within the enum. However, am also experimenting with 
> classes (cue OOP-mumblings, eg "polymorphism", "inversion", ...)
> 
> All the fun of the fair!
> 
> BTW when I reach the point of making comparisons, I expect the enum will 
> be 'cheaper' in storage; but that the dict-construct will be 'faster' - 
> pure speculation(!) Repeating: curious cats, etc...
> 

 From reading the references, especially the second one, it seems to me 
that these new features are mostly intended to handle weird cases 
involving subclasses of enums.  I plan to master these features by 
avoiding them - and hope I never need to understand someone else's code 
that uses them.