[Python-ideas] PEP XXX - Competitor with PEP 435: Adding an enum type to the Python standard library

[Ethan Furman]

On 03/12/2013 03:46 PM, Alex Stewart wrote:
> On Tue, Mar 12, 2013 at 3:16 PM, Ethan Furman <ethan at stoneleaf.us <mailto:ethan at stoneleaf.us>> wrote:
>
>> Sadly, no.  There seems to be two basic camps:  those that think an enum should be valueless, and have nothing to do
>> with an integer besides using it to select the appropriate enumerator (that just looks strange -- I hope you're
>> right Stephen!); and those for whom the integer is an integral part of the enumeration, whether for sorting,
>> comparing, selecting an index, or whatever.
>
> To be honest, I really don't think these two camps are as irreconcilable as lots of people seem to be treating them.  I
> don't think either view is necessarily wrong, and I firmly believe that we can find a common ground that works for both
> ways of approaching this issue.  More importantly, however, I believe we /must/ try to find some way to coexist or
> anything we come up with will be fundamentally inadequate for a substantial portion of the community, and in that case,
> I don't think it belongs in the stdlib.  If we can't compromise a bit, I think we're all doomed to failure.
>
> I do recognize that the issue of transitive equality is something we're going to need to work out.  One thing I think
> folks need to keep in mind, though, is that that issue really has nothing to do with int-enums vs. valueless-enums at
> all.  It will still be a point of contention even if we go with solely the "enums are ints" way of looking at things, so
> that really won't solve it.  (The fundamental issue is: int-enums are (by definition) both ints, and named-objects.
>   When not explicitly or implicitly being used as an int, should they still behave like ints first and named-objects
> second, or should they be named-objects first and ints second?  Both ways have some problems, and we will ultimately
> need to choose which set of problems will be the least annoying in the long term, but that's a completely separate
> discussion than the int/valued/valueless question, IMHO.)

It sounds to me like you might be saying it could be okay to break transitive equality in the case of enums.  I'll quote 
Terry:

On 02/26/2013 07:01 AM, Terry Reedy wrote:
> On 2/25/2013 6:53 PM, Greg Ewing wrote:
>> Barry Warsaw wrote:
>>> --> Colors = make('Colors', 'red green blue'.split())
>>> --> Animals = make('Animals', 'ant bee cat'.split())
>>> --> Colors.green == Animals.bee
>>
>> The currently suggested solution to that seems to be to
>> make comparison non-transitive, so that Colors.green == 1
>> and Animals.bee == 1 but Colors.green != Animals.bee.
>> And then hope that this does not create a quantum black
>> hole that sucks us all into a logical singularity...
>
> But it will;-).
> To repeat myself, transitivity of equality is basic to thought, logic, and sets and we should not deliver Python with it
> broken. (The non-reflexivity of NAN is a different issue, but NANs are intentionally insane.)
>
> Decimal(0) == 0 == 0.0 != Decimal(0) != Fraction(0) == 0
> was a problem we finally fixed by making integer-valued decimals
> compare equal to the same valued floats and fractions. In 3.3:
>
> --> from decimal import Decimal as D
> --> from fractions import Fraction as F
> --> 0 == 0.0 == D(0) == F(0)
> True
>
> http://bugs.python.org/issue4087
> http://bugs.python.org/issue4090
> explain the practical problems. We should NOT knowingly go down this road again. If color and animal are isolated from
> each other, they should each be isolated from everything, including int.

--
~Ethan~