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?
--
Steve
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/5IYULPZNAG4MGTM7UVVAQ7OK5J3ORXSZ/
Code of Conduct: http://python.org/psf/codeofconduct/
