You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add explicit truthiness semantics for constant BooleanExpressions #3543
While this PR can use expression negation via __invert__, I think it may be worth supporting Python truthiness for the constant expressions in a follow-up:
class AlwaysTrue:
def __bool__(self) -> bool:
return True
class AlwaysFalse:
def __bool__(self) -> bool:
return False
That would make patterns like this behave intuitively:
if not self.visit_starts_with(term, literal):
return AlwaysTrue()
When adding this, we should also be careful that Python truthiness is for control flow, not expression construction: not expr returns a Python bool, while ~expr returns a negated BooleanExpression. It would probably be safest for non-constant BooleanExpression.__bool__ to raise, with only AlwaysTrue and AlwaysFalse overriding it. The follow-up should also audit optional-expression checks like expr or AlwaysTrue() and REST residual/filter handling so explicit AlwaysFalse() values are not treated as missing.
It seems like we're trying to get to a place where certain Boolean operators act on the object's presence, while others act on their name. Users shouldn't have to have an understanding of the internals of BooleanExpression to understand how the Python Boolean operators work.
Activity
rambleraptor commentedon Jun 21, 2026
This scares me bit truthfully (pun not intended).
It seems like we're trying to get to a place where certain Boolean operators act on the object's presence, while others act on their name. Users shouldn't have to have an understanding of the internals of BooleanExpression to understand how the Python Boolean operators work.
This only is really a problem for AlwaysFalse()