[Python-Dev] Enumeration items: `type(EnumClass.item) is EnumClass` ?

Guido van Rossum guido at python.org
Mon Apr 29 20:29:22 CEST 2013


You are too verbose. I have already said what I needed to say.

On Mon, Apr 29, 2013 at 11:24 AM, Steven D'Aprano <steve at pearwood.info> wrote:
> On 30/04/13 03:01, Guido van Rossum wrote:
>
>> Oh dear, this is actually a mess. I don't want MoreColor.red and
>> Color.red to be distinct objects, but then the isinstance() checks
>> will become confusing. If we don't override isinstance(), we'll get
>>
>>    not isinstance(Color.red, MoreColor)
>>    isinstance(MoreColor.yellow, Color)
>>
>> This would be pretty backwards.
>
>
> Why is that backwards? MoreColor is a subclass of Color, so instances of
> MoreColor are instances of Color, but instances of Color are not instances
> of MoreColor. That's normal behaviour for subclasses. (All cats are mammals,
> but not all mammals are cats.)
>
> The only "funny" thing about this is that enumeration values of a Enum are
> only instances of that Enum if they are declared inside that Enum, and as
> far as I'm concerned that's not especially funny at all. So:
>
> Color declares red, so Color.red is a Color.
>
> MoreColor does not declare red, it merely inherits it from Color, so
> MoreColor.red is Color.red which is not a MoreColor.
>
>
> This leads to a simple rule:
>
> Enum values are either instances of the enum they are defined in, or
> instances of the parent class they are inherited from.
>
> If the user doesn't like that, they're free to not subclass Enums :-)
>
>
>
>
>> I Ggoogled "enum subclassing" and found this StackOverflow article
>> explaining why you can't subclass enums in Java:
>> http://stackoverflow.com/questions/4604978/subclassing-an-enum which
>> refers to this more elaborate answer:
>>
>> http://stackoverflow.com/questions/3427947/enumeration-inheritence-in-java/3428050#3428050
>
>
> The first link says:
>
> "And generally, a proper subclass is a specialization of its superclass."
>
> and gives the Liskov Substitution Principle as the reason for prohibiting
> subclassing. LSP is a very useful principle, but it is not the only model
> for subclassing. That's why it's called a *principle* and not the Liskov
> Substitution *Law*.
>
> (Yes, I stole that from Raymond Hettinger's talk on subclassing at PyCon.)
>
> I think that the ability to extend enums with new ones, without duplicating
> code, is more important for enums than satisfying LSP. The common use-cases
> for enums do not lend itself to subtyping in the Liskov sense.
>
> E.g. if I have a function that expects a Color red/blue/green enum, and I
> subclass it to give MoreColor yellow, I can't expect the function to
> suddenly recognise yellow. So I'm not going to use subclassing in this case,
> because it can't work.
>
> But I will use subclassing to reuse values: if I have a function that
> expects red/blue/green/yellow, and red/blue/green are already defined in
> Color, I'll want to reuse them rather than duplicate them. Hence I will
> subclass Color specifically to extend it, not to specialise it.
>
>
> The second link quotes:
>
> "For the most part, extensibility of enums turns out to be a bad idea. It is
> confusing that elements of an extension type are instances of the base type
> and not vice versa."
>
> Confusing for who, and why?
>
> You're going to confuse *somebody* no matter what you do. Either:
>
> - confuse people who try to subclass enums, and can't; or
>
> - confuse people who try to subclass enums, and can, but then get confused
> by the result.
>
>
>
>
>
> --
> Steven
>
> _______________________________________________
> 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