Enum + new in 3.11
Thomas Passin
list1 at tompassin.net
Fri Jun 16 21:53:19 EDT 2023
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.
More information about the Python-list
mailing list