[Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

[Guido van Rossum]

On Tue, Apr 23, 2013 at 7:12 PM, R. David Murray <rdmurray at bitdance.com> wrote:
> On Wed, 24 Apr 2013 11:37:16 +1200, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>> R. David Murray wrote:
>> > The first False looks correct to me, I would not expect an enum value to
>> > be an instance of the class that holds it as an attribute.  The second
>> > certainly looks odd, but what does it even mean to have an instance of
>> > an Enum class?
>>
>> This attitude baffles me. In most other languages having a
>> notion of an enum, when you define an enum, you're defining
>> a type. The name of the enum is the name of the type, and
>> its values are instances of that type.
>>
>> Why should our enums be any different?
>
> Obviously they don't need to be, since people have discussed how to
> implement this.
>
> But I am primarily a Python programmer, so my intuition is based on my
> Python experience, not on what other languages do.
>
> Given:
>
>     MyEnum(Enum):
>        a = 1
>        b = 2
>
> I understood that 'a' and 'b' are class attributes, where the int value
> had been transformed into instances of a (separate) value class rather
> than being ints.  The fact that there was a specific value class
> had been discussed.
>
> If 'a' is now an instance of MyEnum, then I would expect that:
>
>     MyEnum.a.b
>
> would be valid (b being an attribute of the MyEnum class which should
> therefore be accessible from an instance of that class).  That seems
> a bit odd, and based on my Python-only mindset, I saw no particular
> reason why an enum value *should* be instance of the enum class, since
> it would lead to that oddity.  (Well, I'm not sure I was concious of
> that *particular* oddity, but in general it seemed like an odd thing to
> have class attributes of a class be instances of that class when the set
> of class attributes was the most important thing about that class...).
> It seemed more natural for the values to be instances of a separate
> value class.
>
> Now, given that I was viewing the Enum as being a collection of attributes
> whose values were instances of a different class, what would it mean
> to create an instance of the Enum class itself?  You'd have an instance
> with access to those class attributes...but the getitem wouldn't work,
> because that's on the metaclass.  You'd really want the Enum class to
> be a singleton...the important thing was that it was an instance of the
> metaclass, its instances would be pretty useless.
>
> I don't have any *problem* with enum values being instances of the class.
> If you make the attribute values instances of the enum class, then
> yes instances of enum class have a meaning.  And then having attributes
> of the class be instances of the class makes perfect sense in
> hindsight.
>
> It's just not where *my* Python-only intuition, or my understanding of
> the discussion, led me.
>
> I feel like I'm revealing my ignorance or stupidity here, but what the
> heck, that's what was going through my brain and I might as well own up
> to it :).

I'm not too worried. Clearly the Enum base class is magic, because,
contrary to the behavior of regular class definitions, MyEnum.a is
*not* just the integer 1 (even if it compares == to 1). At that point
we may as well accept that the entire construct is magic, and the only
consequences we can reason about are those that are documented as
consequences of using this particular kind of magic. I'm not sure that
we can implement a hack to prevent MyEnum.a.b from being an alias for
MyEnum.b, but even if we cannot prevent that, I don't think we need to
worry about it. (However, I suspect we can override __getattr__ to
prevent this if it is considered too unsavory.)

--
--Guido van Rossum (python.org/~guido)