Mailing List Archive

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)?
>
>
> "What's New" says:
> Added the member() and nonmember() decorators, to ensure the decorated
> object is/is not converted to an enum member.
>
> The PSL docs say:
> @enum.member
>     A decorator for use in enums: its target will become a member.
>
> also:
> enum members have names and values (the name of Color.RED is RED, the
> value of Color.BLUE is 3, etc.)
>
> Whereas the "Utilities and Decorators" section is slightly confusing
> because class decorators are mixed with others, so one has to read
> more-carefully.
>
>
> "Curiosity killed the cat" and other cautionary tales/tails...
>
> Have added the following decorated staticmethod to a basic enum. It is
> indeed recognised as a member of the enum, but its value is the
> method-object. To gain the value the method-object represents
> (property-like behavior) one has to call the method/enum-value as a
> function:-
>
>
> from enum import Enum, member
>
>
> class MenuOptions( Enum ):
>     """ Legal menu-choices. """
>     N = "NewGame"
>     L = "LoadGame"
>     # ...
>
>     @member
>     @staticmethod
>     def extra_member()->str:
>         return "QuitGame"
>
>
> def print_demo( enum_chosen:MenuOptions )->None:
>     """ Illustrative printing. """
>     print( "Name:", enum_chosen, enum_chosen.name )
>     if isinstance( enum_chosen, MenuOptions ):
>         print( "Value:", enum_chosen.value )
>
>
> print( MenuOptions.__members__ )
> # {'N': <MenuOptions.N: 'NewGame'>, 'L': <MenuOptions.L: 'LoadGame'>,
> 'extra_member': <MenuOptions.extra_member: <staticmethod(<function
> MenuOptions.extra_member at 0x7f0802128860>)>>}
>
> print_demo( MenuOptions[ "L" ] )
> # Name: MenuOptions.L L
> # Value: LoadGame
>
> print_demo( MenuOptions.extra_member )
> # Name: MenuOptions.extra_member extra_member
> # Value: <staticmethod(<function MenuOptions.extra_member at
> 0x7f0802128860>)>
>
> print( MenuOptions.extra_member.value() )
> # QuitGame
>
>
> Therefore, like an @property decorator applied to a method in a
> custom-class, it could be used to only evaluate some 'expensive'
> computation if/when it is needed. Similarly, it could use the other
> values within the enum in order to present some 'combination'.
>
> Weirdly (given that enums are considered immutable) I imagine that if
> the 'extra_member' were to call some external function with varying
> output, the value could be considered mutable when it is eventually called.
>
> Other?better ideas...

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://github.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....

--
https://mail.python.org/mailman/listinfo/python-list

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
--
https://mail.python.org/mailman/listinfo/python-list

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.

--
https://mail.python.org/mailman/listinfo/python-list