I don't understand why this was cross-posted. Python-Dev removed from addressees. Ethan Furman writes:
When Enum was being designed one of the questions considered was where to start autonumbering: zero or one.
As I remember the discussion we chose not to start with zero because we didn't want an enum member to be False by default, and having a member with value 0 be True was discordant. So the functional API starts with 1 unless overridden. In fact, according to the Enum docs:
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``.
However, if the Enum is combined with some other type (str, int, float, etc), then most behaviour is determined by that type -- including boolean evaluation. So the empty string, 0 values, etc, will cause that Enum member to evaluate as False.
Seems like perfectly desirable behavior to me. A pure enum is a set of mutually exclusive abstract symbolic values, and if you want one of them to have specific behavior other than that you should say so. If you need a falsey value for a variable that takes pure Enum values, "None" or "False" (or both!) seems fine to me depending on the semantics of the variable and dataset in question, and if neither seems to fit the bill, define __bool__. OTOH, an Enum which is conceptually a set of symbolic names for constants of some type should take on the semantics of that type, including truthiness of the values represented. Do you have a use case where that distinction seems totally inappropriate, or have you merely been bitten by Emerson's Hobgoblin?