On Sat, Dec 12, 2020 at 06:00:17PM -0800, Ethan Furman wrote:
Enum is great! Okay, okay, my opinion might be biased. ;)
There is one area where Enum is not great -- for a bunch of unrelated values.
I don't know how to interpret that. Surely *in practice* enums are always going to be related in some sense? I don't expect to create an enum class like this:
class BunchOfRandomStuff(Enum): ANIMAL = 'Mustela nivalis (Least Weasel)' PRIME = 503 EULER_MASCHERONI_CONSTANT = 0.5772156649015329 BEST_PICTURE_1984 = 'Amadeus' DISTANCE_MELBOURNE_SYDNEY = (16040497, "rack mount units")
in any meaningful piece of code, although of course such an eclectic collection is syntactically legal, even if semantically meaningless.
If I did create such an unusual collection of enums, what is the standard Enum lacking that makes it "not great"? It seems to work fine to me.
My proposal, compared/contrasted with Enum:
like Enum, NamedValues will be in collections (a class) that will keep those names from being deleted or rebound to other values
like Enum, NamedValues will have `value` and `name` attributes, and also a `type` attribute
I don't understand this. Are you suggesting that NamedValues will have a `type` attribute **like Enum**, or **in addition** to what Enum provides (value and name)?
I cannot see any sign of a `type` attribute on Enums, but maybe I'm having a Boy Look.
What is the `type` attribute of a NamedValue instance?
[snip a bunch of ways that NamedValues are exactly like Enums]
unlike Enum, duplicates are allowed
Um, do you mean duplicate names? How will that work?
class Stuff(NamedValues): SPAM = 1 SPAM = 2
Stuff.SPAM # what is this???
Enums support duplicate values, and I can't see how duplicate names could work, so I don't get this.
unlike Enum, new values can be added after class definition
Is there a use-case for this?
If there is such a use-case, could we not just given Enums an API for adding new values, rather than invent a whole new Enum-by-another-name?
unlike Enum, a NamedValue can always be used as-is, even if no data type has been mixed in -- in other words, there is no functional difference between MyIntConstants(int, NamedValue) and MyConstants(NamedValue).
Sorry, I don't get that either. How can Enums not be used "as-is"? What does that mean?
Are you suggesting that NamedValue subclasses will automatically insert `int` into their MRO? Otherwise, I don't get how there can be no functional difference between a NamedValue subclass that inherits from int and one that doesn't. Surely you aren't suggesting that this must be meaningful?
class Spam(NamedValue): EGGS = "My hovercraft is full of eels."
Spam.EGGS + 1 # returns what?
Of course I don't think you mean that should actually work, but I cannot think what other interpretation to give your description.
If sre_constants was using a new data type, it should probably be IntEnum instead. But sre_parse is a good candidate for NamedValues:
class K(NamedValues): DIGITS = frozenset("0123456789")
[...snip additional name/value pairs...]
and in use:
>>> K.DIGITS K.DIGITS >>> K.DIGITS.name 'DIGITS' >>> K.DIGITS.value frozenset("0123456789")
Why not just use an Enum?
Sorry Ethan, perhaps I am being slow today, but apart from that "add new members after creation" I fail to see how this is anything but just an Enum. What am I missing?