[Python-Dev] PEP-435 reference implementation (original) (raw)

Guido van Rossum guido at python.org
Wed May 1 18:14:12 CEST 2013

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 <barry at 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 at 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)

More information about the Python-Dev mailing list