<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">> Am 01.05.2013 20:04, schrieb Eli Bendersky:<br>
><br>
> > Actually, in flufl.enum, IntEnum had to define a magic __value_factory__<br>
> > attribute, but in the current ref435 implementation this isn't needed, so<br>
> > IntEnum is just:<br>
> ><br>
> > class IntEnum(int, Enum):<br>
> > '''<br>
> > Class where every instance is a subclass of int.<br>
> > '''<br>
> ><br>
> > So why don't we just drop IntEnum from the API and tell users they should<br>
> do the<br>
> > above explicitly, i.e.:<br>
> ><br>
> > class SocketFamily(int, Enum):<br>
> > AF_UNIX = 1<br>
> > AF_INET = 2<br>
> ><br>
> > As opposed to having an IntEnum explicitly, this just saves 2 characters<br>
> > (comma+space), but is more explicit (zen!) and helps us avoid the<br>
> special-casing<br>
> > the subclass restriction implementation.<br>
><br>
> Wait a moment... it might not be immediately useful for IntEnums (however,<br>
> that's because base Enum currently defines __int__ which I find questionable),<br>
> but with current ref435 you *can* create your own enum base classes with your<br>
> own methods, and derive concrete enums from that. It also lets you have a<br>
> base class for enums and use it in isinstance().<br>
><br>
> If you forbid subclassing completely that will be impossible.<br>
><br>
><br>
> I'm not sure what you mean, Georg, could you clarify?<br>
> This works:<br>
><br>
>>>> from ref435 import Enum<br>
>>>> class SocketFamily(int, Enum):<br>
> ... AF_UNIX = 1<br>
> ... AF_INET = 2<br>
> ...<br>
>>>> SocketFamily.AF_INET<br>
> SocketFamily.AF_INET [value=2]<br>
>>>> SocketFamily.AF_INET == 2<br>
> True<br>
>>>> type(SocketFamily.AF_INET)<br>
> <Enum 'SocketFamily'><br>
>>>> isinstance(SocketFamily.AF_INET, SocketFamily)<br>
> True<br>
><br>
> Now, with the way things are currently implemented, class IntEnum is just<br>
> syntactic sugar for above. Guido decided against allowing any kind of<br>
> subclassing, but as an implementation need we should keep some restricted form<br>
> to implement IntEnum. But is IntEnum really needed if the above explicit<br>
> multiple-inheritance of int and Enum is possible?<br>
<br>
</div></div>Well, my point is that you currently don't have to inherit from int (or IntEnum)<br>
to get an __int__ method on your Enum, which is what I find questionable. IMO<br>
conversion to integers should only be defined for IntEnums. (But I haven't<br>
followed all of the discussion and this may already have been decided.)<br></blockquote></div><br></div><div class="gmail_extra">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.<br>
<br></div><div class="gmail_extra">Ethan - unless I'm missing something, __int__ should probably be removed.<br><br></div><div class="gmail_extra">Eli<br><br></div><div class="gmail_extra"><br><br><br></div></div>