Christopher Barker writes:
> e.g.: what are the valid values?
That's easy: MyEnum.__members__.
Seriously? you are arguing that Enums are better because they are self documenting, when you have to poke at a dunder to get the information ?!?
I'm actually kind of surprised there isn't an obvious way to check that.
2. The class attribute __doc__ is treated specially: it does not
become an Enum member, and it is treated as you would expect by
help().
OK, so this is one advantage (for the use case at hand) you can put the docs for what the NaNFlags are in teh Enum docstring, and then it is documented for all function that use that flag.
However, this is helpful (and DRY) for the author of the package -- but I think less useful for the users of the package.
I want to (in iPython) do:
statistics.median?
and see everything I need to know to use it, not get a reference to an Enum that I then need to go look up.
> But what they do is create a burden of extra code to read and write.
I think more likely it would be
from statistics import median
from statistics import NANPolicy as NP
result = median(the_data, nans=NP.OMIT)
Exactly -- this is a fair bit more awkward than:
from statistics import median
result = median(the_data, nans="omit")
I suppose less so if you are using more than a couple calls to statistics functions, but how common is that?
Python 3.11 Enums have the global_enum decorator, which injects the
members into the global namespace. Then the above could be:
from statistics import median
from statistics.nanpolicy import *
result = median(the_data, nans=OMIT)
hmm, I suppose I'd follow numpy tradition, and do:
import statistics as st
result = st.median(the_data, nans=st.OMIT)
but that only makes sense for numpy because we tend to use a LOT of numpy once we are using any :-)
But: if an ENUM is used, do please put all the flags in the statistics namespace.
-CHB