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

[Eli Bendersky]

On Mon, Mar 11, 2013 at 10:25 AM, Ethan Furman <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> 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.

To summarize, my personal preference in priority order is:

1. get flufl.enum into stdlib, or a similarly simple proposal
2. don't get any enum package into stdlib at this point
3. get this alternative 4-class approach into stdlib

Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130312/3ffe95b5/attachment.html>