<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 1, 2013 at 10:48 AM, Guido van Rossum <span dir="ltr"><<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">On Wed, May 1, 2013 at 10:21 AM, Ethan Furman <<a href="mailto:ethan@stoneleaf.us">ethan@stoneleaf.us</a>> wrote:<br>


> We may not want to /completely/ disallow subclassing.  Consider:<br>
><br>
> --> class StrEnum(str, Enum):<br>
> ...    '''string enums for Business Basic variable names'''<br>
> ...<br>
> --> class Vendors(StrEnum):<br>
> EnumError: subclassing not allowed<br>
><br>
><br>
> My point is that IntEnum, StrEnum, ListEnum, FloatEnum are all "subclasses"<br>
> of Enum.  To then have a subclass of<br>
> that, such as Season(StrEnum), is subclassing a subclass.<br>
<br>
</div>True, and Enum itself also falls in this category. Maybe there could<br>
be a special marker that you have to set in the class body (or a<br>
keyword arg in the class statement) to flag that a class is meant as a<br>
"category of enums" rather than a specific enum type. Such categorical<br>
classes should not define any instances. (And maybe "defines no<br>
instances" is enough to flag an Enum class as subclassable.)<br>
<div class="im"><br>
> Now, if we do want to completely disallow it, we can ditch IntEnum and force<br>
> the user to always specify the mixin<br>
> type:<br>
><br>
> --> class Season(str, Enum):<br>
>          .<br>
>          .<br>
>          .<br>
><br>
> --> class Names(str, Enum):<br>
>          .<br>
>          .<br>
>          .<br>
><br>
> But that's not very user friendly... although it's not too bad, either.<br>
<br>
</div>Indeed, given that we mostly want IntEnum as a last-resort backward<br>
compatibility thing for os and socket, it may not be so bad.<br>
<div class="im"><br></div></blockquote><div><br></div><div>Actually, in flufl.enum, IntEnum had to define a magic __value_factory__ attribute, but in the current ref435 implementation this isn't needed, so IntEnum is just:<br>

<br>class IntEnum(int, Enum):<br>    '''<br>    Class where every instance is a subclass of int.<br>    '''<br><br></div><div>So why don't we just drop IntEnum from the API and tell users they should do the above explicitly, i.e.:<br>

<br></div><div>class SocketFamily(int, Enum):<br></div><div>  AF_UNIX = 1<br></div><div>  AF_INET = 2<br><br></div><div>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.<br>

<br>Eli<br></div></div><br></div></div>