Message248394
@serhiy.storchaka: It's somewhat of a special case, to be sure. However, I do think it's justified to put it into the base (rather than a user type) for three reasons:
1) It makes IntEnum and Enum consistent. IntEnum actually already handles this case just fine, because it's an int and therefore already supports __bool__ correctly. It feels odd that changing the storage format from an IntEnum to a Enum should break the logic- correctly used, the actual enum values should never matter. This small change just brings them into line.
2) It is less surprising than the current case; I discovered this when I did something like the Enum.Nope case here, and I naively used the enum in an if statement, assuming that the value would control the __bool__ value. (This was caught by my tests, of course, but the point remains that I wrote the code). Normally in python, you'd expect the default bool conversion to be unconditionally True, but enums aren't really normal objects; for any use case for which there is a default noop value, you'd generally put that value _into_ the enum:
class FilterType(Enum):
NONE = None
SUB = 'Sub'
UP = 'Up'
...
3) It's not logically inconsistent with the idea of Enums. The other dunder methods you mention aren't consistent with the concept: __float__ (enum values aren't generally numbers except as an implementation detail), __lt__ (enums aren't generally ordered), __len__ (enums aren't generally containers). The one thing an enum does have is a value, and it feels consistent to me to check the truthiness of an enum without having to reach into the .value to do so.
Anyway, that's my case for inclusion! |
|
Date |
User |
Action |
Args |
2015-08-11 06:15:25 | novas0x2a | set | recipients:
+ novas0x2a, r.david.murray, ethan.furman, serhiy.storchaka |
2015-08-11 06:15:25 | novas0x2a | set | messageid: <1439273725.42.0.785745227098.issue24840@psf.upfronthosting.co.za> |
2015-08-11 06:15:25 | novas0x2a | link | issue24840 messages |
2015-08-11 06:15:23 | novas0x2a | create | |
|