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. On Fri, Jan 15, 2016 at 10:22 AM, Ethan Furman <ethan@stoneleaf.us> wrote:

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.

So the question now is: for a standard Enum (meaning no other type besides Enum is involved) should __bool__ look to the value of the Enum member to determine True/False, or should we always be True by default and make the Enum creator add their own __bool__ if they want something different?

On the one hand we have backwards compatibility, which will take a version to change.

On the other hand we have a pretty basic difference in how zero/empty is handled between "pure" Enums and "mixed" Enums.

On the gripping hand we have . . .

Please respond with your thoughts on changing pure Enums to match mixed Enums or any experience you have had with relying on the "always True" behaviour or if you have implemented your own __bool__ to match the standard True/False meanings or if you have implemented your own __bool__ to match some other scheme entirely.

-- ~Ethan~ _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

-- --Guido van Rossum (python.org/~guido)

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?

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. On Fri, Jan 15, 2016 at 10:22 AM, Ethan Furman <ethan@stoneleaf.us> wrote:

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.

So the question now is: for a standard Enum (meaning no other type besides Enum is involved) should __bool__ look to the value of the Enum member to determine True/False, or should we always be True by default and make the Enum creator add their own __bool__ if they want something different?

On the one hand we have backwards compatibility, which will take a version to change.

On the other hand we have a pretty basic difference in how zero/empty is handled between "pure" Enums and "mixed" Enums.

On the gripping hand we have . . .

Please respond with your thoughts on changing pure Enums to match mixed Enums or any experience you have had with relying on the "always True" behaviour or if you have implemented your own __bool__ to match the standard True/False meanings or if you have implemented your own __bool__ to match some other scheme entirely.

-- ~Ethan~ _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

-- --Guido van Rossum (python.org/~guido)

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?