Repository navigation
Optional "no truth value testing" mode #1730
Description
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.
Activity
rwbarton commentedon Jun 22, 2016
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 writesuser.is_adminthinkingis_adminis a property when it's actually a method returningbool, it's almost certainly a bug.tigrfhluerh commentedon Jun 22, 2016
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 commentedon Jan 19, 2017
@tigrfhluerh are you still planning on working on this? If not, I'd be happy to do it.
Herst commentedon Mar 20, 2017
Sorry for hijacking this issue, but does using flag lead to good style or not?
After all it goes against PEP 8, e.g.:
gvanrossum commentedon Mar 20, 2017
gvanrossum commentedon Mar 20, 2017
ddfisher commentedon Mar 21, 2017
--strictis 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 commentedon Mar 21, 2017
Yeah, so IMO it's useless. Maybe we should get rid of it.
ddfisher commentedon Mar 22, 2017
We seem to have several enthusiastic users of
--strictas-is, though!gvanrossum commentedon Apr 18, 2017
We're considering killing this option, as it complicates maintenance and it's an unpythonic requirement. See discussion in #3185.