[Python-ideas] PEP XXX - Competitor with PEP 435: Adding an enum type to the Python standard library

[Ethan Furman]

On 03/12/2013 05:23 AM, Eli Bendersky wrote:
>
> On Mon, Mar 11, 2013 at 10:25 AM, Ethan Furman <ethan at stoneleaf.us <mailto:ethan at stoneleaf.us>> wrote:
>
>     On 03/11/2013 09:55 AM, Paul Moore wrote:
>
>         On 11 March 2013 16:18, Ethan Furman <ethan at stoneleaf.us <mailto:ethan at stoneleaf.us>> wrote:
>
>             First, I offer my apologies to all who are still battle-weary from the last
>             flurry of enum threads.
>
>         [...]
>
>             This new PEP proposes an enum module that handles all those use cases, and
>             makes it possible to handle others as well.
>
>
>         One thing that is not discussed in the PEP (at least from my quick
>         reading of it) is the issue of transitivity of equality
>
>
>     There are four types you can inherit from: Enum, BitMask, Sequence, and String.
>     Enum, BitMask, and String will not compare equal with integers, and Enum, BitMask
>     and Sequence will not compare equal with strings; in fact, Enum and Bitmask, not
>     being based on an existing data type, will not compare equal with anything that is
>     not in their own enumeration group or its superclass.  Sequences will
>     compare equal with ints, because they are ints;  they will also compare equal
>     against other Sequence enumerations, as they are also ints.  Same deal with
>     Strings and strs.  Those two are basically NamedValues in a fancy enum package.
>
>
> 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).
>
> 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.

Would it be easier to accept if it was called "Enums and other Named Constants"?

Currently, if I want to store a list of homogeneous values I can use:

   - list
   - tuple
   - bytes
   - bytearray
   - array.array

Are these not "slightly different in subtle ways"?

If simple is what we want, then do away with the "an enum is not an int" idea, toss out the "Color.red != 
OtherColor.red", and suddenly my four classes are down to two (int vs str), or flufl.enum suddenly handles many many 
more cases than it did before.

But, quite frankly, I see value in having different enumerations being different types, and in having NamedConstants... 
  perhaps some renaming would make things clearer?

Currently:

     EnumType

     Enum(metaclass=EnumType)

     BitMask(metaclass=EnumType)

     Sequence(metaclass=EnumType)

     String(metaclass=EnumType)


Could be instead:

     NamedConstantType

     Enum(metaclass=NamedConstantType)

     NamedInt(int, metaclass=NamedConstantType)

     NamedStr(str, metaclass=NamedConstantType)

with available add-ons of BITMASK, INDEX, and ORDER.

I don't know about you, but I like that a lot better.  :)

--
~Ethan~