Personally I would probably compare enums using ==, but I agree that 'is' should also work -- since the instances are predefined there's no reason to ever have multiple equivalent instances, so we might as well guarantee it.
I'm sorry that my requirements for the relationship between the enum class and its values ends up forcing the decision not to allow subclasses (and I really mean *no* subclasses, not just no subclasses that add new values), but after thinking it all over I still think this is the right way forward. Something has got to give, and I think that disallowing subclasses is better than having the isinstance relationships be inverted or having to test for enum-ness using something other than isinstance. I guess the only way to change my mind at this point would be to come up with overwhelming evidence that subclassing enums is a very useful feature without which enums are pretty much useless. But we'd probably have to give up something else, e.g. adding methods to enums, or any hope that the instance/class/subclass relationships make any sense. Contravariance sucks. On Wed, May 1, 2013 at 8:44 AM, Barry Warsaw <ba...@python.org> wrote: > On Apr 30, 2013, at 10:50 PM, Ethan Furman wrote: > >>The way I had subclassing working originally was for the subclass to create >>it's own versions of the superclass' enum items -- they weren't the same >>object, but they were equal: >> >>--> class Color(Enum): >>... red = 1 >>... green = 2 >>... blue = 3 >> >>--> class MoreColor(Color): >>... cyan = 4 >>... magenta = 5 >>... yellow = 6 >> >>--> Color.red is MoreColor.red >>False >> >>--> Color.red == MoreColor.red >>True >> >>If you switched from `is` to `==` would this work for you? > > Not really, because in practice you don't compare one enum against another > explicitly. You have a value in a variable and you're comparing against a > literal enum. So `is` is still the more natural spelling. > > My point is, if you want enums to behave more class-like because you're using > the class syntax, then you shouldn't explicitly break this one class-like > behavior just to protect some users from themselves. There doesn't even seem > to be an easy way to override the default behavior if you really wanted to do > it. > > -Barry > _______________________________________________ > 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/guido%40python.org -- --Guido van Rossum (python.org/~guido) _______________________________________________ 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