Rule suggestion: ban implicit truthy/falsey type conversion in truth value testing

[kkom]

Suggestion

Ban code like this:

def foo() -> int:
    ...

def optional_foo() -> int | None:
    ...

x = foo()

if x:  # lint error here
    ...

if not x:  # lint error here
    ...

y = foo()

if y:  # lint error here
    ...

if not y:  # lint error here
    ...

Examples of code that would pass this rule:

if x != 0:
    ...

if x == 0:
    ...

if y is not None:
    if y == 0:
        ...
    else:
        ...

if y is None:
    ...

I don't think an autofixer for this rule is needed, or even desired – as the motivation is for the programmer to be explicit about what conditions they are evaluating, rather than relying an implicit catch-all check.

int is just an example, but I would like the rule to flag such usage of any type other than bool (so also str, list, set, custom objects – everything).

Motivation

Python allows any object to be used in conditionals (if, while or as an operand of boolean operations) – thanks to the __bool__() and __len__() special methods. See:

• truth value testing
• __bool__
• __len__

However, this behaviour is quite implicit and can lead to undesired outcomes. In my opinion, it at the least hides nuanced logic and makes the code non-obvious – more difficult to read and reason about.

• There is one bug I see all the time, which is caused by special treatment of 0 as falsy, but any other int as truthy.
  • Programmers often want to proceed if a value has been provided (int), but not if it wasn't (None) – writing just if x: ... results in bundling "good" 0 values with the "bad" None values.
• However, more nuanced issues may occur too:
  • Empty string "" is often considered undesired, but it is still distinct from None and may be sometimes fine.
  • The same goes for an empty list [] or set set() – they occasionally represent perfectly correct values (empty, rather than missing data), which a sloppy if x: ... check would discard.
  • etc.

More generally, Python (unlike e.g. Java or Go) has the great advantage of having an explicit None type, which type checkers like mypy and Pyright understand and refine through advanced static type inference (e.g. flow-sensitive typing).

This makes it possible to lean on optional types like str | None, int | None, list[object] | None and x is None checks – allowing the type checker to refine the types and avoid checks being redundantly repeated:

def maybe_int() -> int | None:
    ...

x = maybe_int()

if x is None:
    return "early return because we're missing data"

x  # the type has been now refined to just `int`

To benefit from this, some codebases will even define custom types such as:

class NonEmptyString(str):
    __slots__ = ()

    def __init__(self, x: str) -> None:
        if len(x) == 0:
            raise ValueError("Provided an empty string")

        super().__init__()

Where NonEmptyString | None can be passed around and tested for bad data exactly once.

A "no truthy check" rule like this would be intended to be used in such codebases.

PS: It's inspired by Facebook's PHP/Hack rule called no-sketchy-null-check (I forget the exact name). It's the opposite of PLC1901, so they shouldn't be both enabled at the same time.

Questions

1. Curious to hear your thoughts on such a rule!
2. How possible is this, given that Ruff isn't a static type checker? I do see a number of type-related rules though (even PLC1901), so I hope something is possible!

[kkom]

Some more materials for reference:

• I opened an issue on this in Pyright's discussions as well, as I imagine this check might be easier to implement using the type checker, rather than linter.
  • Some good comments from @erictraut there: Optional rule suggestion: ban implicit truthy/falsey type conversion in truth value testing microsoft/pyright#6488 (comment)
    • Including a pointer to this ESLint rule: https://github.com/typescript-eslint/typescript-eslint/blob/main/packages/eslint-plugin/docs/rules/strict-boolean-expressions.md
  • I've been also pondering that an integration between a linter and typechecker could unlock a bunch of reliable, type-informed opinionated rules like this... Optional rule suggestion: ban implicit truthy/falsey type conversion in truth value testing microsoft/pyright#6488 (reply in thread)
• Some more reference on how this works at Facebook in PHP/Hack: https://hhvm.com/blog/2018/08/28/hhvm-3.28.0.html (search for sketchy null check)

[dpinol]

@kkom did you find any tool which implements this check?

[kkom]

@dpinol – no, but there are quite a few voices of support for it here: microsoft/pyright#6488

you should add a comment as well, if you'd like to see this rule!