Let's drop --strict-boolean

[gvanrossum]

See discussion in #3185 -- it's not working perfectly and it is encouraging bad style. It also makes --strict less useful: it means you can't use --strict if you don't believe in --strict-optional, else you'd get a ton of false positive from the latter.

[gvanrossum]

Or at least start deprecating it and remove it from --strict.

[pkch]

Before we proceed with this, I just wanted to clear up one thing based on the earlier discussion on gitter.

Would this flag become useful if it was restricted just to the cases where it's actually unsafe? Specifically the usage of non-boolean variable in a boolean context is unsafe only if it has more than 1 values that is interpreted as False:

def f(x: int) -> None:
  if x:  ... # safe
 
def g(x: int = None) -> None:
  if x:  ... # unsafe; is x 0 or None?
 
def h(x: set) -> None:
  if x: ... # safe

def i(x: set = None) -> None:
  if x: ... # unsafe; is x an empty set or None?

def j(x: Callable[[int], int] = None) -> None:
  if x: ... # safe

def k(x: bool = None) -> None:
  if x: ... # unsafe; is x False or None?

It seems very easy to identify unsafe cases, using the truth value testing rules. The usage is unsafe if the variable type is a Union that includes more than one of the following types:

• None
• a numeric type
• a subtype of Sized
• a type that has __bool__ method defined

(Edit: The last bullet point can wait until we have structural types)

Do you want me to check if restricting --strict-boolean to just these cases would make sense, perhaps using mypy own source code?

[JukkaL]

Agreed -- it's not worth having --strict enable it, and the entire option is questionable.

@pkch We can discuss that as a separate feature (which might perhaps share a name with the current option). Feel free to open an issue for it.

[JelleZijlstra]

When --strict-boolean was added I tried it on my codebase and found it way too pedantic to be useful. Maybe some people really like writing if len(lst) > 0: instead of if lst:, but I don't think mypy needs to enforce that.

However, there are some related checks that mypy could do that are actually useful, like warning if you do if some_object.is_foo instead of if some_object.is_foo() (where is_foo is a method). But those kinds of things can be discussed in a separate issue.

[gvanrossum]

Regarding the idea that conflating an empty something (or zero) with None is a bad idea, it is actually quite common to have code that does this intentionally, and uglifying it just doesn't seem right.

So let someone please volunteer for a PR that deprecates it and removes it from the --strict set. (Explicit --strict-boolean or the corresponding config flag should still work for one more release, but with a deprecation message.)

[viktor25]

I use --strict-boolean, but I did not see this thread until I read the 0.510 release notes. Is the decision to remove it set in stone? Is there any possibility to leave it, possibly under a less pretentious name (e.g. --insane-boolean), and not as part of --strict?

Alternatively, is there an easy way to create a mypy wrapper that adds back the functionality?

[JukkaL]

@viktor25 The feature as it was implemented was problematic, since it actually doesn't do the right thing in all cases (as discussed in #3185 and elsewhere). We could perhaps add a fixed version of the feature at some point (but not enable it through --strict), but as it's at least somewhat complicated, the core team won't have bandwidth to discuss and review the feature at least in the near term. Feel free to reopen the discussion at a later date, say 6 months from now. Things may be different by then.

[gvanrossum]

Honestly I strongly believe it's an anti-pattern to do this in Python and I don't want to support a feature (even if contributed). Sorry.