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/