[Python-ideas] PEP XXX - Competitor with PEP 435: Adding an enum type to the Python standard library
ethan at stoneleaf.us
Tue Mar 12 15:36:22 CET 2013
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:
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?
Could be instead:
with available add-ons of BITMASK, INDEX, and ORDER.
I don't know about you, but I like that a lot better. :)
More information about the Python-ideas