SupportsBool - an abc for bool-like objects

[wittekm]

Warning: This is sort of a weird use case.

In our codebase, we have

class FalseWithAssociatedReason(object):
 def __init__(self, reason):
 self.reason = reason

 def __nonzero__(self):
 # This object is always false in a boolean context.
 return False

The usecase for this is something like the following

def parameter_equals_one(param):
 # type: (Any) -> ???
 if param == 1:
 return True
 else:
 return FalseWithAssociatedReason("Param {} is not 1.".format(param))

def main(...):
 result = parameter_equals_one("2345")
 if not result:
 print result.reason

There's no return type we can use for parameter_equals_one that wouldn't be a union. I propose a SupportsBool abc that FalseWithAssociatedReason could inherit from.

(Only catch: I believe falseness is described by both __nonzero__ and __len__.)

And to those who say the above use case can be covered by exceptions: hey, you're not wrong, but this is a hyper-simplified usecase.

[JukkaL]

One possibility is to use the type bool for this and have a helper that casts FalseWithAssociatedReason to bool, perhaps something like this:

def false_with_reason(reason):
 # type: (str) -> bool
 return FalseWithAssociatedReason(reason) # type: ignore

def parameter_equals_one(param):
 # type: (Any) -> bool
 if param == 1:
 return True
 else:
 return false_with_reason(...)

[dmoisset]

Actually any object has a "truthiness" value in python... after finding similar problems I just declared SupportsBool = object, and then parrameter_equals_one could return SupportsBool. This actually IMO is better than bool which still can be used as a number (True ** -1, True.imag) with no complaints from either python or mypy.

Your problem here is that the print(result.reason) call will now fail, but I don't see that being solved without using a Union, or having your own version of True which has a reason attribute.

[nmarrow]

Stumbled across this because I was looking for almost the same thing. I believe there is a much less esoteric use case here. Consider the functions:

def is_foo_enabled():
 """Returns if foo is enabled"""

def remaining_foo_count():
 """Returns the length of foo objects left to process."""

def are_foos_remaining():
 """Returns if foo is enabled and there are foos to process."""
 return is_foo_enabled() and remaining_foo_count()

Here are_foos_remaining will return a truthy or falsey object. As a developer, I may believe that the exact implementation of are_foos_remaining may change, but that it will also return values that should be evaluated in a boolean context. It's possible to type the return type as object, but this conveys no actual meaning to someone reading the function. Why does it return object? If it were typed as something like -> SupportsBool (or just Bool?) then it's clear that the return value should be treated like an implicit boolean only.

[srittau]

This should now be implementable using protocols. The following passes mypy:

from typing import Protocol


class SupportsBool(Protocol):
 def __bool__(self) -> bool: ...

class Falsy:
 def __bool__(self) -> bool:
 return False

def is_bool(x: bool) -> SupportsBool:
 if x:
 return True
 else:
 return Falsy()
 
if is_bool(True):
 pass

[emmatyping]

There was a recent issue on the mypy tracker asking about this, and I think if someone wants to see such a protocol added to typing in the stdlib they should open a request on bugs.python.org.