[Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library
Russell E. Owen
rowen at uw.edu
Fri Apr 12 20:21:09 CEST 2013
In article
<CAP7+vJLUO0B0y+=Jcg8D=jQ3mggSAm1tb9ZzttO7nCrKE6Mh6Q at mail.gmail.com>,
Guido van Rossum <guido at python.org> wrote:
> On Fri, Apr 12, 2013 at 9:34 AM, Guido van Rossum <guido at python.org> wrote:
> > To me, NotImplementedError means that a subclass didn't implement
> > something it should have implemented. But that's not the case here, is
> > it? It's not a bug in the class, it's a bug in the call site. So I
> > agree it ought to be TypeError.
>
> Seems I was late to this particular argument. :-)
>
> Anyway, as far as I can tell the PEP looks great. I personally think
> it would be nicer if regular Enums were ordered (as long as the
> underlying values are ordered), but I don't care enough to overrule
> the FLUFL.
I, too, would strongly prefer to see ordering within an enum. I use
home-made enums heavily in my code and find ordering comparisons useful
there.
Using intEnum is certainly doable, but that opens up the door to
comparing values from different Enums, which is not something I'd want
to allow.
I don't understand why order tests are seen as a bad thing, as long as
the values have order (as they will in the common cases of string and
int values). It seems the code must go out of its way to prohibit such
tests.
In any case, I'm very pleased to have this library. it will get rid of
much boilerplate in my code. It seems very well designed, and I'm really
glad to see it supports subclassing to add values!
-- Russell
More information about the Python-Dev
mailing list