[Python-Dev] Enumeration items: `type(EnumClass.item) is EnumClass` ?
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev