Enum + new in 3.11

[dn]

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...

-- 
Regards,
=dn