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

Larry Hastings larry at hastings.org
Mon Apr 29 20:34:59 CEST 2013


On 04/29/2013 10:01 AM, Guido van Rossum wrote:
> On Mon, Apr 29, 2013 at 9:12 AM, Ethan Furman <ethan at stoneleaf.us> wrote:
>> On 04/29/2013 08:39 AM, Guido van Rossum wrote:
>>> Indeed, the "type(Color.red) is Color" claim was meant for the
>>> situation where red is defined directly in Color, and I used type()
>>> instead of isinstance() because Barry was proposing to overload
>>> isinstance() to make this true without equating the classes. But for
>>> the subclass case, I want MoreColor.red is Color.red and
>>> isinstance(MoreColor.red, Color), but not isinstance(Color.red,
>>> MoreColor). If you can't live with that, don't subclass enums.
>>
>> So if I understand:
>>
>> --> class Color(Enum):
>> ...     red = 1
>> ...     green = 2
>> ...     blue = 3
>>
>> --> class MoreColor(Color):
>> ...     cyan = 4
>> ...     magenta = 5
>> ...     yellow = 6
>>
>> --> type(MoreColor.red) is Color
>>
>> --> type(MoreColor.red) is not MoreColor
>>
>> In other words, while `red` is accessible in MoreColor, it's actually a
>> Color instance?
> 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.

What's the problem with overriding the isinstance checks?  You mention 
it but seem to assume it's a bad idea.  That seems to me like it'd 
adequately solve that problem with an acceptable level of magic.


//arry/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130429/dd06033e/attachment.html>


More information about the Python-Dev mailing list