[Python-Dev] enum instances

Marco Hemmelrath marco.hemmelrath at googlemail.com
Tue Apr 30 03:23:06 CEST 2013

First of all, hi, I'm new to this list.

Following the enum discussions on this list I am kind of confused about 
how enums and their respective instances, i.e. the values, should behave 
in "normal" context.
I apologize beforehand for the mass of "questions" because the following 
contains really many discussed things but they all kinda depend on one 
another, and for terminology which I might've missed.

Considering we have[1]:

     class Color(enum):
         red = 1
         white = 2
         other = "undefined"

     class State(enum):
         idle = 0
         busy = 1
         idling = idle
         ideling = 0

together with the premises:

     1. type(State.busy) == State
     2. type(State) == enum
     3. isinstance(State.idle, State)
     4. State.idle is State.idle

which should mostly be agreed on (if I didn't misinterpret).

How would an enum instance (e.g. State.busy) behave in normal Python 
expressions? Should these instances just wrap their values and provide 
some simple overhead useful for enums?

I'll just note down a few examples of how I think it could work and 
express a few thoughts on them:

     1. State.busy == 1
     2. State.busy == Color.red
     3. int(State.Busy) is 1
     4. isinstance(State.busy, int)
     5. Color.other.startswith("und")
     6. State.busy is not 1
     7. State.busy is not Color.red
     8. State.idle in State
     9. 0 in State # True, False or raise?
     10. State.idling is State.idle
     11. State.idle == State.idling
     12. State.idle is not State.idling

1. & 2.
Considering that enum components contain a value this value should be 
accessable and comperable. If it wasn't then there would be no real need 
to assign a value to it because everything must be compared using the is 
operator anyway. In this case an entirely new syntax could be 
implemented but since I think this is not what we want I'll skip this.

Futhermore, if enum instances should compare equal to their values but 
unequal to each other this creates weird circumstances like:
Color.red == 1 == State.busy -but- Color.red != State.busy == 1

Similar to 1. an enum instance's value /should/ be accessable as an 
expression by itself when needed besides simple operations like 
compatisons. This might be really tricky because the object in question 
is still of type State and some existing uses might break even though I 
can't think of any.

What would certainly be a problem in this case though is that repr() 
would not reveal the value but the actual enum instance. This could be 
problematic when the enum instance's value is not a standard type or 
when repr() and str() differ and repr() is what's needed.

Combines 1. and 2. in class relation. It could be argued that the actual 
value should be an instance of its type subclassed by the enum class 
(State) which is in turn a subclass of enum.

Going further on this it could also allow various things like class 
EnumWithInt(enum, int) which would only allow integers as its enum 
identifiers. This goes slightly into the IntEnum direction but with more 

Related to 3. in that this also allows attribute access to the enum 
instance's value. Considering that the enum instance should already be 
an instance of its value type as well this kinda speaks for itself.

6. & 7.
Obviously, these can't be true even though they compare equal (see 1. 
and 2.).

Check if an enum instance is a member of State. Since in this case the 
same can also be achieved by using isinstance or by comparing the 
instance's type, this is mostly interesting for subclassing enums 
because, but I won't that cover here because it would probably be too much.

Analog to 8. this could either return just work, simply return False 
because this object is obviously not a member of State or raise an 
exception because of a type mismatch (not an enum instance). Also 
interesting for subclassing enums.

See premise 4. on this.

11. & 12.
Even though these compare equal and even if their value object is 
actually the same they themseves should /not/ be the same object. 
Someone needs to find a use case for this though because as of now I can 
only think of this being Pythonic.

So, the most critical part of this would probably be 3. to 7. regarding 
the value types. I'd love to read some thoughts and comments on that.


[1]: http://mail.python.org/pipermail/python-dev/2013-April/125738.html

More information about the Python-Dev mailing list