False positive: possibly-used-before-assignment doesn't understand and-ed contions

[skirpichev]

Bug description

# pylint: disable=missing-module-docstring,invalid-name
a = bool(input())
b = bool(input())

if a:
    c = 123

if a and b:
    print(c)  # report possibly-used-before-assignment

if a:
    c += 1  # ok

Configuration

No response

Command used

pylint bug.py

Pylint output

************* Module bug
bug.py:9:10: E0601: Using variable 'c' before assignment (used-before-assignment)

------------------------------------------------------------------
Your code has been rated at 3.75/10 (previous run: 3.75/10, +0.00)

Expected behavior

No errors

Pylint version

pylint 3.2.2
astroid 3.2.2
Python 3.11.3+ (heads/3.11:9fbb614c4e, Apr 29 2023, 14:18:05) [GCC 10.2.1 20210110]

OS / Environment

No response

Additional dependencies

No response

[Pierre-Sassoulas]

Thank you for the nice reproducer !

[jacobtylerwalls]

@Pierre-Sassoulas is it too confusing that we made a limited exception for the last if consisting of the "exact same test"? Should we just always emit a message?

[Pierre-Sassoulas]

Sorry I did not remember about this. I suppose undertanding that if an arbitrarily complex conditional is true another arbitrarily complex conditional is also true might be useful in a lot of place. My uneducated guess is that implementing this perfectly would range from hard to impossible for implementation and costly to very costly in performance. Maybe we can expand what we have progressively ? As in right now we handle exact match, and we could maybe handle exact match and and coming from the local scope and expand from there, if reasonable ?

[jacobtylerwalls]

Sorry I did not remember about this. I suppose undertanding that if an arbitrarily complex conditional is true another arbitrarily complex conditional is also true might be useful in a lot of place.

No worries. I'm just not sure if we want to encourage pylint to go down this path. I don't think it's really about conditionals, it's more about whether pylint should have line-by-line knowledge of the possible values of variables.

The point of #9628 is that I can make this unsafe...

a = False
b = True
if a:
    c = 123

if a and b:
    print(c)  # report possibly-used-before-assignment

by doing this...

a = False
b = True
if a:
    c = 123

a = not a

if a and b:
    print(c)  # crashes

If you're okay with that pattern, because you don't care whether the middle part of your function grows more complex over time, then this isn't the message for you, and you should disable it.

Constraints like we added in astroid for is None guards are different; instead, here we're talking about trying to guess what the value of a is after not a (or something more complicated).

[Pierre-Sassoulas]

Isn't guessing what the value of a variable is, what inference is about (i.e. it would expand what infer is capable of if we have good control flow) ?

[jacobtylerwalls]

Okay, right. I guess we could check for the absence of any other assignments to a in between if a and if a and ... before deciding that if a and ... is as safe as if a. Without being on the hook for trying to come up with a whole truth table for every possible permutation, which would be pointless.