Optional "no truth value testing" mode

[tigrfhluerh]

Feature request:
Make it possible to tell mypy to treat the following as errors:

if None:
    pass
if 1:
    pass
if [1, 2, 3]:
    pass
if "asdf":
    pass

class A:
    def __bool__(self):
        return True
a = A()
if a:
    pass

(This list is based on the "Truth Value Testing" section in https://docs.python.org/3/library/stdtypes.html)

The goal is to force the developer to use explicit coercions like:

if x is not None:
    pass
if x != 0:
    pass
if len(x) > 0:
    pass
if bool(x):
    pass

Of course libraries and stubs should not be affected by this restriction.

The rationale is that while truth value testing is a valuable shortcut for many people, it also causes bugs, so some projects might want to force their developers to use explicit coercions.

[rwbarton]

This would be technically pretty easy to implement, perhaps you'd like to give it a shot?

I tend to be a fan of the "conditions must be bools" style you propose, though I'm not sure how popular it is among Python programmers in general. In some cases, though, mypy could reasonably be more opinionated even by default. For example, if the programmer writes user.is_admin thinking is_admin is a property when it's actually a method returning bool, it's almost certainly a bug.

[tigrfhluerh]

Yes, I'd like to give it a shot. I expect to have some free time in early July. Once I know roughly what changes I want to make, I will outline them here to see if they make sense. Thanks!

[afrieder]

@tigrfhluerh are you still planning on working on this? If not, I'd be happy to do it.

[Herst]

Sorry for hijacking this issue, but does using flag lead to good style or not?

After all it goes against PEP 8, e.g.:

For sequences, (strings, lists, tuples), use the fact that empty sequences are false.

Yes: if not seq:
     if seq:

[gvanrossum]

I personally see no value in enforcing this, but apparently some people do. Style can be a personal choice. The option will always remain off by default. (Hm, should `--strict` turn it on? I hope not, it would make `--strict` much more annoying.)

[gvanrossum]

(Sadly it is.)

[ddfisher]

--strict is a weird beast. It's only meant to be used if you want all possible strictness checks (which apparently some people do). I really want to avoid it becoming "all recommended strictness checks", because I don't think that's generally meaningful (as it really depends on the project) and because I don't want us to have another place where we have to make editorial decisions.

[gvanrossum]

Yeah, so IMO it's useless. Maybe we should get rid of it.

[ddfisher]

We seem to have several enthusiastic users of --strict as-is, though!

[gvanrossum]

We're considering killing this option, as it complicates maintenance and it's an unpythonic requirement. See discussion in #3185.