On Thursday, February 21, 2013 11:54:49 AM UTC-8, Joao S. O. Bueno wrote:
4. They should subclass INTs in way it is possible to interact with low level
libraries already using C Enums (only aplicable to those that need an
int value) -
their use should be as transparent as True and False are today.
Ok, I can see that would be a desirable trait (and personally I'm with you on that one), though I'm not sure it really qualifies as "required" (there are potential uses for int-enums which would still be useful/valid even if it couldn't do that automatically), but I'll definitely add that to my "desirable" list..
>1. Enums should represent themselves (str/repr) by symbolic names, not as ints,
> etc.
I would say that, while not "required", as low level languages lack this,
the whole idea is simply not worth implementing without this. This is the
real motivation - and NB. also for "Constants", not only "Enums".
Frankly, I think this one is so easy it's really not worth fussing about that much. It's pretty much a given that any solution we come up with will have this functionality anyway..
>2. Enums from different groups should preferably not compare equal to each
> other (even if they have the same associated int value).
I am not shure about this requirement. I agree about "valueless" Enums, but
as far as they have values associated, they should behave just like
their values. I did not hear of anyone injured by " True == 1" in Python.
Well, it's explicitly not a requirement (that's why it's under "desirable" instead of "required"). Here's the question, though: Do you believe if a solution was proposed which had this property it would be a bad thing?
Note that this isn't really exactly the same as the "True == 1" case. In my opinion the argument in favor of this is along the lines of:
class FooOptions (Enum):
YES = 1
MAYBE = 2
NO = 3
class BarOptions (Enum):
NO = 1
MAYBE = 2
YES = 3
def foofunc(choice):
if choice == FooOptions.YES:
do_something()
Now what if somebody calls foofunc(BarOptions.NO)?
Admittedly, this is a somewhat exaggerated case, but I still think it would be better if in these sorts of cases FooOptions.YES != BarOptions.NO (if one explicitly did want to test if the values were the same (regardless of enum type) they could do something like "if int(choice) == FooOptions.YES" instead)
--Alex