Consider adding `--non-numeric-bool` mode

[sobolevn]

As it was discussed in #8069, sometimes we need to logically separate int and bool types.

Currently mypy allows this to happen:

def some(a: int): ...

some(x > 1)

Because bool is subtype of int. I am proposing to add a strict-bool mode, so bool would be treated as a non-int type. And this code would generate an error.

It can be a new config option: --strict-bool or a new disabled by default error code in the future as @JukkaL suggested.

[hauntsaninja]

Agree that this could be useful. For an amusing real life instance of this problem: psf/black#762 followed by psf/black#1092

[Akuli]

this happens to me a lot, and I think this could be a more useful behaviour for a --strict-bool flag:

def foo() -> bool:
    ...

if foo:
    ...

Functions are not bools, so this problem occurs only when if or while or something else converts things to bool implicitly. With --strict-bool-conversion, if foo would be allowed only in these cases:

• type of foo is bool
• type of foo is Optional[something]
• type of foo is Any
• type of foo has __bool__
• type of foo has __len__ (python handles foo.__len__() == 0 even without overriding __bool__)

[Akuli]

type of foo is Optional[something]

Maybe instead of this, it should be more general, such as "type of foo is a Union such that some unioned types can be true and some can be false". This way, Optional[Literal[False]] aka Union[None, Literal[False]] would be disallowed.

[Akuli]

I think my previous two comments can be ignored. There's already --warn-unreachable, which partially solves my problem.

[JukkaL]

Since we now support enabling individual error codes (#9172), this should be implemented as one or more optionally enabled error codes instead of a command-line flag such as --strict-bool.

We may want two separate error codes, since there are at least two separate issues that would be useful to catch:

• Using bool as a subtype of int (at least in many contexts -- this may be hard to implement in full generality).
• Using callable type or Type[x] in a boolean context, such as if func: (when it should be if func():), or possibly what @Akuli suggested above, but it might be noisy.

Additionally, --strict should probably enable these error codes.

[sobolevn]

Using callable type or Type[x] in a boolean context, such as if func: (when it should be if func():), or possibly what @Akuli suggested above, but it might be noisy.

Highly related #10666

[jorenham]

but

>>> issubclass(bool, int)
True