[Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library (original) (raw)

Eli Bendersky eliben at gmail.com
Fri Apr 12 23:54:18 CEST 2013

On Fri, Apr 12, 2013 at 2:17 PM, R. David Murray <rdmurray at bitdance.com>wrote:

On Fri, 12 Apr 2013 14:06:55 -0700, Eli Bendersky <eliben at gmail.com> wrote: > I actually think that having values with different types within a single > Enum is conceptually wrong and should be disallowed at creation time. With > enums, you either care or don't care about their actual value. If you don't > care (the most common use case of an enum, IMHO), then no problem here. If > you do care, then it's probably for very specific reasons most of which are > solved by IntEnum. I can't imagine why someone would need differently typed > values in a single enum - this just seems like a completely inappropriate > use of an enum to me.

I'm sure someone will come up with one :) Which is precisely the reason to ban it :)

But seriously, even if you require all values to be of the same type, that doesn't solve the sorting problem:

>>> class Foo(enum.Enum): ... aa = object() ... bb = object() ... >>> Foo Traceback (most recent call last): File "", line 1, in File "./enum.py", line 103, in repr for k in sorted(cls.enums))) TypeError: unorderable types: object() < object() Now, you could further require that the type of enum values be sortable....but that point you really have no excuse for not allowing enum values to be compared :)

I'm actually not really in favor of enum values being comparable. I think this is more a C-ism and does not cleanly settle with my concept of what an enum is. For comparable enums and other C-derived properties, IntEnum is out there, so call it maybe ;-)

Eli -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20130412/82c70ecc/attachment-0001.html>

More information about the Python-Dev mailing list