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

[kkom]

I've started a discussion on this on Ruff's GitHub, but I'm also curious if this is something that Pyright might consider implementing.

I'd like to ban implicit truthy/falsy checks in our codebase, to avoid common bugs like this:

def maybe_int() -> int | None:
    """returns None if data is missing, otherwise the value"
    ...

x = maybe_int()

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

# we now have a bug, because `0` is a perfectly fine value, but it was discarded in the early return above

process_data(x)

More details and broader rationale in this discussion: astral-sh/ruff#8757

@erictraut – what's you view on this? Does this feel like a rule Pyright might implement? (I would imagine it would be optional even in strict mode.)

On one hand it feels opinionated enough to be a linter rule, on the other hand I have a hunch it might be easier and more robust to implement in a type checker (feels a bit similar to e.g. reportUnnecessaryComparison).

[erictraut]

This pattern has legitimate uses and is quite common in Python, so it's not a rule that could be enabled by default, even in strict mode. In general, I don't like adding rules that cannot be enabled by default in strict mode because they are difficult for pyright users to discover and therefore are rarely used. This situation is also not a type violation, which means that it's not obvious that it's a rule a type checker should be enforcing.

There is a precedent for pyright supporting rules that are not type violations but do require type analysis (and are therefore difficult for linters to implement). These rules all involve cases where 1) there's a relatively low chance of a false positive and 2) a reasonably high likelihood of an actual bug. The reportUnnecessaryComparison rule is a good example of such a rule.

This particular check doesn't seem to meet this bar. I'm not convinced that it represents a sufficiently common source of bugs to merit adding such a rule, but I could perhaps be persuaded with some additional evidence.

For comparison, the typescript compiler (which is effectively a static type checker) does not provide an option like the one you're proposing, but eslint (which is more akin to a ruff) does.

[kkom]

Thank you for the response. I understand the discoverability problem of beyond-strict rules...

When I received your response, I was typing an additional comment giving an example why I think the type-checker is better suited for a rule like this. Consider code like this:

def maybe_bool() -> bool | None:
    ...

x = maybe_bool()

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

if x:
    # do something because `x` is `True`
else:
    # do something because `x` is `False`

I don't see like a linter could understand that the if x: line is fine (because the type has been narrowed to bool from bool | None). I assume that such type narrowing is the domain of the typechecker, rather than linter.

I have a follow-on thought. Have you seen close integration between a type-checker and a linter in the past? The type checker could provide type inference functionality, which the linter would use to implemented opinionated rules like the one I proposed.

If this hasn't been done before, what are you thoughts on this?

(I'm a happy user of both Ruff and Pyright, and while I'm not involved with any of the projects directly, I think an integration like this could unlock a lot of benefits.)

[kkom]

In terms of any additional validation, I can share that Facebook has enabled a rule like this in its PHP/Hack codebase (through the HHVM typechecker) a few years ago. It's a little confusingly called sketchy null check, but has worked well in the codebase.

See these release notes for some reference: https://hhvm.com/blog/2018/08/28/hhvm-3.28.0.html

[erictraut]

Have you seen close integration between a type-checker and a linter in the past? The type checker could provide type inference functionality, which the linter would use to implemented opinionated rules like the one I proposed.

It's an interesting idea. In theory, ruff could do that today using pyright's language server interface. It would do this by instantiating the pyright language server and then passing it a "hover text" request for a particular position within the file. Pyright would then evaluate the type of the identifier at that location and pass back the hover text, which includes the identifier's narrowed type. The downside is that the output of the hover text LSP command is text (specifically, markdown), so ruff would need to parse the text and convert it back into its own representation of a type.

In theory, an alternative interface could be added to pyright that effectively does the same thing as the "hover text" request but returns type information in a manner that doesn't require conversion from text. The encoding would need to be agreed upon by tools vendors — and preferably standardized in a specification. There's currently no provision in the language server protocol for encoding type information. That's understandable given that the LSP is language-agnostic, but types are language-specific.

If you or someone else is interested in prototyping this idea using the current facilities in pyright, you could look at my implementation of the web-based pyright playground. It does something similar to what I'm describing above. It installs the pyright language server from the npm registry and instantiates it, then sends it LSP messages to retrieve diagnostics, hover text, completion suggestions, etc.

[hmc-cs-mdrissi]

One idea I've considered for building on top of pyright to use type of expressions for custom logic/tooling was to take code like this,

def foo(x: int) -> str:
  y = "a"
  z = y + str(x)
  return z

and then rewrite ast (ast.parse -> NodeTransformer -> ast.unparse if done in python) and dump it into something like,

def foo(x: int) -> str:
  y = reveal_type("a")
  z = reveal_type(y + str(x))
  return z

Exactly how much to reveal_type depends on which nodes you need type information for (assignments, if condition, return expresssion, etc). Then run pyright --outputjson on the new file and extract the type information from json.

For this specific idea it should be possible to parse AST -> add reveal_type for every if statements condition -> run pyright -> extract type information for if statements -> define lint rule. This is roughly taking python AST and creating an AST + type information and more reveal_types you put in the closer it becomes to that.

[patrick-kidger]

but I could perhaps be persuaded with some additional evidence.

Since this was mentioned, I'd like to chime in with an additional +1 for this feature.

The examples given elsewhere in this thread are exactly the ones that I find people bumping into. Here's my own flavour of this:

def f(random_seed: Optional[int]):
    if not random_seed:
        random_seed = seed_from_system_time()
    ...    # do stuff deterministically on `random_seed`

f(0)  # Silently not deterministic!