[Python-ideas] PEP for enum library type?

[Joao S. O. Bueno]

On 21 February 2013 22:58, Rob Cliffe <rob.cliffe at btinternet.com> wrote:
> Apart from the point about maybe wanting to order enums, I agree.  I think
> Alex is right when he says you want to create singleton enums that don't
> equate to anything else.  We don't think of RED, GREEN, BLUE as being
> identical with the ints 1,2,3, and so don't want our implementation of them
> to compare equal to those ints.


Again, I thinnkt hat my 2002 code that expected a (1) working when it
got a (True) instead was a great, great thing. And I think that lots
of places where magical strings today ("str.decode" errors argument,
"compile" mode argument) should be lifted up to expect constants and
still keep working if one pass them the strings "replace" or "eval".

Requiring that things compare differently, IMHO, is too much
statically-typed-minded - it is not the way of Python. As for Alex's
surreal example of  someone defining "NO" and "YES" with different
values in different Enums and passing the wrong one to a given call -
this person will have it comming. Think of this case instead:

>>> disk_io.IDDLE == "iddle"
True
>>> network.IDDLE == "iddle"
True
>>> disk_io.IDDLE == network.IDDLE
False

So, if the compared enums do have an explicit value assigned to them
(and I agree there are some cases the value is not needed) , they
should compare just as that value - anything else is more close to C++
than Python.

And no one is preventing people from using decorators or use other
mecanisms for certain function calls to accept only values of a given
Enum, just as no one ever was prohibited from statically verifying any
other values in a call.