Baike.dev
Log in
Back to tool/Back to issues
#4519·ty

Follow-up tasks for `redundant-condition(-strict)` rules

Author: AlexWaygoodCreated Sep 12, 2026Updated Sep 16, 2026

  1. Mypy's truthy-function rule also triggers for Callable annotations; ours does not, currently, because we model non-function-like Callables as having ambiguous truthiness (Multiplay gist: d120c34286b5c1b438f128e33cdbc789). We could experiment with having a third rule that triggers on Callable-annotated variables that are used in boolean contexts. Similarly, mypy's truthy-iterable error code flags arbitrary Iterable[]- and Iterator[]-typed variables used in boolean contexts. We currently only flag generators, since Iterable and Iterator have ambiguous truthiness.

  2. Similarly, mypy's redundant-expr diagnostic triggers on code such as this (multiplay gist: bdd9ec316ce12e024e6be186392bd703), which is not flagged by any ty rule currently:

    python
    def normalize(s: str):
   return s is not None and s

    It would be good to look into exactly what heuristics mypy is using to flag that without having too many false-positive errors. We left all and and or expressions out of the initial implementation when they occurred outside boolean tests; it felt too complex to get this right without too many false positives. Perhaps we could flag these as part of redundant-condition(-strict), or perhaps we could have a separate rule for cases like this.

  3. The rules currently err on the side of caution by assuming that this assert is meant to mark the branch as "deliberately unreachable", because the assert could evaluate to False:

    python
    def f(x: int, y: bool):
    if not isinstance(x, int):
        assert y

    That probably leads to us having false negatives in some situations; it would be good to experiment with this and see if refining the heuristic to only count assert statements that are definitely False actually leads to an increase in false positives or not

  4. Add subdiagnostics highlighting the reachability impliciations of a test being either always-truthy or always-falsy.

  5. Currently we only flag assert statements if the type of the test being asserted is not assignable to bool or int. But perhaps we could also detect cases like this, where it appears that the suite below the assert is intended to be reachable, but we infer the assert as always failing due to the condition always being falsy:

    python
    assert 1 == 2
print('this looks like it was meant to be reachable')

    https://github.com/astral-sh/ruff/pull/28357

  6. Currently we assume that any condition that is an AST-literal True, False, 1 or 0 is deliberate. But maybe we should flag something like this, on the grounds that it clearly looks like the suite after the while is meant to be reachable?

    python
    while True:
    pass
print('this looks like it was meant to be reachable')

  7. Suppress diagnostics on Call expressions that return None, when they occur inside and, or or not expressions? These often have side effects.

  8. Move "short-circuit" conditions from redundant-condition-strict to redundant-condition?

  9. Improve internal and external documentation reguarding "short-circuit" conditions, per @carljm's excellent analysis here

Source: astral-sh/ty

View original on GitHubView discussion on GitHub