On Fri, Apr 12, 2013 at 2:17 PM, R. David Murray <rdmur...@bitdance.com>wrote:
> On Fri, 12 Apr 2013 14:06:55 -0700, Eli Bendersky <eli...@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 "<stdin>", line 1, in <module> > 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
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
