[Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as (original) (raw)

Tim Delaney timothy.c.delaney at gmail.com
Tue Feb 26 21:52:54 CET 2013

On 27 February 2013 01:50, Terry Reedy <tjreedy at udel.edu> wrote:

On 2/25/2013 12:35 PM, Ethan Furman wrote:

But this I don't, and in both mine, Ted's, and Alex's versions enums from different groups do not compare equal, regardless of the underlying value. Of course, this does have the potential problem of green == 1_ _== bee but not green == bee which would be a problem with set and dicts -- but I'm the only one who has brought up that issue.

I have not been following the discussion in detail so I missed that before. Breaking transitivity of equality a no-no. It is basic to thought and logic. decimal(0) == 0 == 0.0 != decimal(0) was a problem we finally fixed by removing the inequality above. http://bugs.python.org/**issue4087 <http://bugs.python.org/issue4087> http://bugs.python.org/**issue4090 <http://bugs.python.org/issue4090> We should NOT knowingly re-introduce the same problem again! If color and animal are isolated from each other, they should each be isolated from everything, including int.

FWIW the only reason I made my enums int-based (and comparable with ints) was because I read somewhere that Guido had said that any stdlib enum would have to be an int subclass.

I have no problems with having int-like enums that:

  1. Are not int subclasses;

  2. Do not compare equal with ints unless explicitly converted.

I do think an int-like enum should implement both int and index.

Tim Delaney -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20130227/73824e02/attachment.html>

More information about the Python-Dev mailing list