[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