[Python-Dev] PEP-435 reference implementation
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