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

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