Am 01.05.2013 23:48, schrieb Eli Bendersky:

> � � Well, my point is that you currently don't have to inherit from int (or IntEnum)
> � � to get an __int__ method on your Enum, which is what I find questionable. �IMO
> � � conversion to integers should only be defined for IntEnums. �(But I haven't
> � � followed all of the discussion and this may already have been decided.)
>
>
> Good point. I think this may be just an artifact of the implementation - PEP 435
> prohibits implicit conversion to integers for non-IntEnum enums. Since IntEnum
> came into existence, there's no real need for int-opearbility of other enums,
> and their values can be arbitrary anyway.

OK, I'm stupid -- I was thinking about moving the __int__ method to IntEnum
(that's why I brought it up in this part of the thread), but as a subclass of
int itself that obviously isn't needed :)

You did bring up a good point, though - __int__ should not be part of vanilla Enum.

Eli

">

(original) (raw)




On Wed, May 1, 2013 at 2:52 PM, Georg Brandl <g.brandl@gmx.net> wrote:
Am 01.05.2013 23:48, schrieb Eli Bendersky:

\> � � Well, my point is that you currently don't have to inherit from int (or IntEnum)
\> � � to get an \_\_int\_\_ method on your Enum, which is what I find questionable. �IMO
\> � � conversion to integers should only be defined for IntEnums. �(But I haven't
\> � � followed all of the discussion and this may already have been decided.)
\>
\>
\> Good point. I think this may be just an artifact of the implementation - PEP 435
\> prohibits implicit conversion to integers for non-IntEnum enums. Since IntEnum
\> came into existence, there's no real need for int-opearbility of other enums,
\> and their values can be arbitrary anyway.

OK, I'm stupid -- I was thinking about moving the \_\_int\_\_ method to IntEnum
(that's why I brought it up in this part of the thread), but as a subclass of
int itself that obviously isn't needed :)

You did bring up a good point, though - \_\_int\_\_ should not be part of vanilla Enum.

Eli