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
