On 26/04/13 18:00, Greg Ewing wrote:
However, there's a worse problem with defining enum inheritance that way. The subtype relation for extensible enums works the opposite way to that of classes.To see this, imagine a function expecting something of type Colors. It knows what to do with red, green and blue, but not anything else. So you *can't* pass it something of type MoreColors, because not all values of type MoreColors are of type Colors. On the other hand, you *can* pass a value of type Colors to something expecting MoreColors, because every value of Colors is also in MoreColors. Moreover, suppose we have another type: class YetMoreColors(Colors): orange = 4 purple = 5 pink = 6 Now suppose a function expecting Colors gets an enum with the integer value 4. How should it be interpreted? Is it cyan or orange? What about if you write it to a database column and read it back?
There are many places where Python demands an actual int, not a subclass. See the recent thread "Semantics of __int__, index". There's no reason why a function that expects a Color *must* accept subclasses as well. If it can, great. If it can't, document it and move on. It's not Color's responsibility to know everything about every subclass. Invert your thinking: the subclasses are in charge, not Color. Color can't be expected to give a value to 4. Only the subclass that defines it can. This is only a problem if you believe that subclassing == taxonomy hierarchy. It isn't. http://pyvideo.org/video/879/the-art-of-subclassing -- Steven _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
