<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>