[Python-Dev] Enum: subclassing? (original) (raw)

Eli Bendersky eliben at gmail.com
Wed May 1 23:48:08 CEST 2013

> Am 01.05.2013 20:04, schrieb Eli Bendersky: > > > Actually, in flufl.enum, IntEnum had to define a magic valuefactory > > attribute, but in the current ref435 implementation this isn't needed, so > > IntEnum is just: > > > > class IntEnum(int, Enum): > > ''' > > Class where every instance is a subclass of int. > > ''' > > > > So why don't we just drop IntEnum from the API and tell users they should > do the > > above explicitly, i.e.: > > > > class SocketFamily(int, Enum): > > AFUNIX = 1 > > AFINET = 2 > > > > As opposed to having an IntEnum explicitly, this just saves 2 characters > > (comma+space), but is more explicit (zen!) and helps us avoid the > special-casing > > the subclass restriction implementation. > > Wait a moment... it might not be immediately useful for IntEnums (however, > that's because base Enum currently defines int which I find questionable), > but with current ref435 you can create your own enum base classes with your > own methods, and derive concrete enums from that. It also lets you have a > base class for enums and use it in isinstance(). > > If you forbid subclassing completely that will be impossible. > > > I'm not sure what you mean, Georg, could you clarify? > This works: > >>>> from ref435 import Enum >>>> class SocketFamily(int, Enum): > ... AFUNIX = 1 > ... AFINET = 2 > ... >>>> SocketFamily.AFINET > SocketFamily.AFINET [value=2] >>>> SocketFamily.AFINET == 2 > True >>>> type(SocketFamily.AFINET) > <Enum 'SocketFamily'> >>>> isinstance(SocketFamily.AFINET, SocketFamily) > True > > Now, with the way things are currently implemented, class IntEnum is just > syntactic sugar for above. Guido decided against allowing any kind of > subclassing, but as an implementation need we should keep some restricted form > to implement IntEnum. But is IntEnum really needed if the above explicit > multiple-inheritance of int and Enum is possible?

Well, my point is that you currently don't have to inherit from int (or IntEnum) to get an int method on your Enum, which is what I find questionable. IMO conversion to integers should only be defined for IntEnums. (But I haven't followed all of the discussion and this may already have been decided.)

Good point. I think this may be just an artifact of the implementation - PEP 435 prohibits implicit conversion to integers for non-IntEnum enums. Since IntEnum came into existence, there's no real need for int-opearbility of other enums, and their values can be arbitrary anyway.

Ethan - unless I'm missing something, int should probably be removed.

Eli -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20130501/2513234a/attachment.html>

More information about the Python-Dev mailing list