[Python-ideas] PEP for enum library type?

[Alex Stewart]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130221/5e96d408/attachment.html>