On Mon, Apr 29, 2013 at 2:45 PM, Terry Jan Reedy <tjreedy@udel.edu> wrote:

On 4/29/2013 8:24 AM, Eli Bendersky wrote:

Thanks for the summary. One issue I don't see addressed here is
int-compatibility. Am I correct to assume that nothing changes w.r.t.
that, and that an IntEnum subclass of Enum will be provided which is
isinstance(integer)? Does that become straightforward by nature of enum
values being the type of their enumerations?

My only concern is that whatever you do does not break transitivity of ==. Aside from that, I will be happy with whatever you end up with and use it as appropriate.

The transitivity of == is not broken by either proposal. In PEP 435, the split to Enum and IntEnum is made in part for this reason. Enum values don't compare equal even if they have the same underlying values. IntEnum values do compare equal to ints, and hence to each other. So:

class Color(Enum):

red = 1

blue = 2

class Animal(Enum):

dog = 2

sheep = 7

Color.blue != Animal.dog, and neither compares to 2, of course.
However, had both enums been IntEnum, we'd have:

Color.blue == Animal.dog == 2

This is a werdness users of IntEnum have to live with, and that's why it's explicitly discouraged for 99% of the use-cases.

Eli