<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 11, 2013 at 10:25 AM, Ethan Furman <span dir="ltr"><<a href="mailto:ethan@stoneleaf.us" target="_blank">ethan@stoneleaf.us</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 03/11/2013 09:55 AM, Paul Moore wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 11 March 2013 16:18, Ethan Furman <<a href="mailto:ethan@stoneleaf.us" target="_blank">ethan@stoneleaf.us</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
First, I offer my apologies to all who are still battle-weary from the last<br>
flurry of enum threads.<br>
</blockquote>
[...]<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This new PEP proposes an enum module that handles all those use cases, and<br>
makes it possible to handle others as well.<br>
</blockquote>
<br>
One thing that is not discussed in the PEP (at least from my quick<br>
reading of it) is the issue of transitivity of equality<br>
</blockquote>
<br></div>
There are four types you can inherit from: Enum, BitMask, Sequence, and String.<br>
Enum, BitMask, and String will not compare equal with integers, and Enum, BitMask<br>
and Sequence will not compare equal with strings; in fact, Enum and Bitmask, not<br>
being based on an existing data type, will not compare equal with anything that is<br>
not in their own enumeration group or its superclass.  Sequences will<br>
compare equal with ints, because they are ints;  they will also compare equal<br>
against other Sequence enumerations, as they are also ints.  Same deal with<br>
Strings and strs.  Those two are basically NamedValues in a fancy enum package.<br><div class="im"></div></blockquote><br></div>First of all, thanks for working on this. It's healthy to have several approaches to solve the same problem. That said, I'm very much against the alternative you propose. The reason boils down to basic Pythonic principles. I imagine myself a few years from now reading Python 3.4+ code and seeing usage of these Enum, BitMask, Sequence (Integer?) and String classes, all slightly different in subtle ways, and that imaginary self will no doubt reach for the reference documentation on every occasion. That's because the 4 are similar yet different, and because they have no parallel in the C/C++ world (at least most of them don't).<br>

<br>On the other hand, with flufl.enum, *because* it's so simple, it's very easy to grasp pretty immediately since it has few well defined uses cases that are similar in spirit to C's enum. Yes, in some cases I won't be able to use flufl.enum, and I'll fall back to the current "solution" of not having an enum package at all. But in the cases where I use it, I'll at least know that my code is becoming more readable.<br>

<br>To summarize, my personal preference in priority order is:<br><br></div><div class="gmail_extra">1. get flufl.enum into stdlib, or a similarly simple proposal<br></div><div class="gmail_extra">2. don't get any enum package into stdlib at this point<br>

</div><div class="gmail_extra">3. get this alternative 4-class approach into stdlib<br><br>Eli<br></div><div class="gmail_extra"><br><br></div><div class="gmail_extra"><br></div></div>