PEP 661: Sentinel Values

[HexDecimal (Kyle Benesch)]

@rrolls

Assuming that we do get customisable bool behavior, I think it’s more likely that in a given situation, some sentinel will be invented that has “natural” bool behavior for the circumstances, and then when someone sees list[SomeClass | SomeSentinel] or the like, the thought will be “aha, there can be this particular sentinel in there” (and recalling the bool behavior of that particular sentinel will come naturally), not “hmm, there could be a sentinel in here… what’s its bool behavior?”.

Taking SomeClass always being True for granted can lead to logical errors later on. Adding a SomeClass.__len__ method would be enough to break any assumptions being made here.

The purpose of a new sentinel is to be a unique type/value which will not collide with existing types or values. Sorting types by truthiness defeats this purpose by allowing sentinels to collide with arbitrary types of similar truthiness.

In fact it feels like some are accidentally advocating for None to exist when it already does. If one wants a falsy sentinel which they do not need to use identity comparisons with then None already does everything they want. The semantics of if x: are important to understand here and it feels like people are not taking it as seriously as they should. Sentinels removing support for __bool__ would force people to respect that if x: truly does not separate sentinels from arbitrary types instead of giving a false hope that it does.

@rrolls

[…] but the situations where that behavior feels unnatural (even if that behavior is “raise TypeError”) will cause a headscratching moment.

For TypeError its error message could explain using identity comparisons:

TypeError: SomeSentinel is not convertible to bool
Did you mean 'x is SomeSentinel' or 'x is not SomeSentinel'?