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

[Tim Delaney]

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>