Flag `None` check on value that cannot be `None`

[nickdrozd]

Say I have function that maybe returns None and I check the result:

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

if f() is None: ...

I rewrite the function so that it never returns None:

def f() -> int: ...

if f() is None: ...

Now the is None check makes no sense -- it will always fail. This is a mistake introduced in refactoring and it should be flagged. (And similar for is not None checks)

In Rust I don't think this kind of error is possible:

fn f() -> Option<u8>;

if f().is_none() {} // okay

fn g() -> u8;

if g().is_none() {} // no good

[A5rocks]

Both --warn-unreachable and --strict-equality should work for this. But they don't! That's a bug.

Maybe worth closing this to make a bug report? Or someone can change tags (I can't :'( ).

[nickdrozd]

Forgot to add, this affects Mypy 1.14.1 with Python 3.14, using --strict setting. (Not sure if --warn-unreachable is included in that, but if it isn't it should be.)

Switching the tag from feature to bug is fine with me :)

[A5rocks]

It isn't included in that. Maybe thumbs up #18078!

[nickdrozd]

Here is a full example:

from random import randrange

def f(x: int) -> int | None:
 return None if x == 0 else 2 * x

def g(x: int) -> int:
 return 2 * x

if __name__ == '__main__':
 if f(randrange(10)) is None:
 print('f: got 0')

 if g(randrange(10)) is None: # <-- unreachable but not flagged
 print('g: got 0')

mypy --strict --warn-unreachable does not raise any warnings, but it should. So this is a FALSE NEGATIVE bug. Or a new feature, whatever, but in any case this situation should be flagged.

[tyralla]

This recently confused me too, but in my case, --warn-unreachable fired but --strict-equality did not:

g = 1
if g is None:
 y = 1 # error: Statement is unreachable
print(y)

def f() -> int:
 return 1
if f() is None:
 x = 1
print(x)

Regarding --warn-unreachable, this really seems like a bug to me. However, regarding --strict-equality, it is (or, at least, was) intentional. See #6370 and here:

mypy/mypy/checkexpr.py

Lines 3772 to 3780 in 116b92b

	Rules:
	* X and None are overlapping even in strict-optional mode. This is to allow
	'assert x is not None' for x defined as 'x = None # type: str' in class body
	(otherwise mypy itself would have couple dozen errors because of this).
	* Optional[X] and Optional[Y] are non-overlapping if X and Y are
	non-overlapping, although technically None is overlap, it is most
	likely an error.
	* Any overlaps with everything, i.e. always safe.
	* Special case: b'abc' in b'cde' is safe.

I opened #19718 as an experiment. It's not only Mypy that would need many type: ignore's or changes....

Excluding assert statements (like Pyright does) would help a little. Alternatively, we could eventually introduce a --strict-equality-for-none flag for a while???