There's a slightly odd edge case which can be summarized as follows:

====================
from enum import Enum

class Bool(Enum):
    Yep = True
    Nope = False

for value in Bool:
    print('%18r is %r' % (value, bool(value)))
====================

output:
====================
  <Bool.Yep: True> is True
<Bool.Nope: False> is True
====================

This isn't really a big deal, but can be made better with the attached patch. I can't think of any odd consequences this might cause, but others may know better.

No patch is attached.

@r.david.murray man you're fast :) Sorry, realized I forgot to actually run the tests for 3.5 and 3.4, I'd only run them for master (I've now run them for 3.5 and 3.4 now, too).

(I should note that I just recently signed the contributor agreement, not that this a particularly complex fix, but it hasn't propagated to my profile yet).

This looks to me as very special case. Enum doesn't delegates the __bool__ method as well as it doesn't delegates __float__, __lt__, __len__, etc. It is left to user to add these methods if needed.

It is easy to add the __bool__ method to user enum. In your case you also can inherit from IntEnum.

>>> class Bool(IntEnum):
...     Yep = True
...     Nope = False
... 
>>> bool(Bool.Yep)
True
>>> bool(Bool.Nope)
False

@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!

I agree that it seems odd that testing a 'value' that is false for its truth value would return True.  It is surprising, even if it is an edge case.

Thanks for finding that, Mike.

I'll review and merge in the next few days.

New changeset 87a9dff5106c by Ethan Furman in branch 'default':
Close issue24840: Enum._value_ is queried for bool(); original patch by Mike Lundy
https://hg.python.org/cpython/rev/87a9dff5106c

This change breaks existing code that is relying on the behavior of the enum API as shipped in 3.4 and 3.5.  Please do NOT do this.

Worse, you've landed this change in a "stable" release of the enum34 "backport" module (1.1.1) despite it never having been released as a stable Python API.  Please do not let *the backport* get ahead of the latest stable released Python API.

https://bitbucket.org/stoneleaf/enum34/issues/10/versions-of-enum34-111-break-support-for

The enum34 backport has been fixed to not have 3.6 only features (assuming the __bool__ change was the only one).

Was that your only objection, or do you not want this change in 3.6 either?

lets collect some examples of where it causes problems (someone ran into the problem at work which is why i hunted down this bugs.python.org issue) before deciding.

If it stays in, it needs a mention in both Misc/NEWS and What's New as it will require some people to test and update their code for 3.6.  Examples will let us decide which way to go.

Mike, my apologies.  In the future I'll make sure and read the docs before I go through with changes.

In the docs (https://www.python.org/dev/peps/pep-0435/#id35):

    The reason for defaulting to 1 as the starting number and
    not 0 is that 0 is False in a boolean sense, but enum members
    all evaluate to True.

From a newer discussion on Python Ideas and Python Dev:

Barry Warsaw:
    I think in general enums are primarily a symbolic value and don't
    have truthiness.  It's also so easy to override when you define
    the enum that it's not worth changing the current behavior.

Guido van Rossum:
    Honestly I think it's too late to change. The proposal to change
    plain Enums to False when their value is zero (or falsey) would
    be a huge backward incompatibility. I don't think there's a reasonable
    path forward, and also don't think there's a big reason to regret
    the current semantics.

Thank you, Gregory, for catching that.

New changeset: 52dc28ee3c88

I think it is better to use "value" instead of "_value_" in the documentation.

New changeset e4c22eadc25c:

use public 'value'

messages: + msg256869

resolution: fixed -> (no value)

nosy: + python-dev
messages: + msg250932

resolution: fixed
stage: patch review -> resolved