Let's drop --strict-boolean #3195

Activity

1. gvanrossum commented on Apr 19, 2017

   

   gvanrossum

   on Apr 19, 2017

   MemberAuthor

   More actions

   Or at least start deprecating it and remove it from --strict.
2. pkch commented on Apr 19, 2017

   

   pkch

   on Apr 19, 2017

   Last edited by pkch

   Contributor

   More actions

   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?
3. JukkaL commented on Apr 19, 2017

   

   JukkaL

   on Apr 19, 2017

   Collaborator

   More actions

   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.
4. JelleZijlstra commented on Apr 19, 2017

   

   JelleZijlstra

   on Apr 19, 2017

   Member

   More actions

   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.
5. gvanrossum commented on Apr 19, 2017

   

   gvanrossum

   on Apr 19, 2017

   MemberAuthor

   More actions

   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.)
6. gvanrossum

   closed this as completedin #3197on Apr 21, 2017
7. viktor25 commented on May 18, 2017

   

   viktor25

   on May 18, 2017

   More actions

   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?
8. JukkaL commented on May 18, 2017

   

   JukkaL

   on May 18, 2017

   Collaborator

   More actions

   @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.
9. gvanrossum commented on May 18, 2017

   

   gvanrossum

   on May 18, 2017

   MemberAuthor

   More actions

   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.
10. gvanrossum

    added 2 commits that reference this issue on Oct 5, 2018

    Deprecate --strict-boolean

    ...

    946be60

    Remove deprecated options, including --strict-boolean (#5740)

    ...

    df4432f
11. ikonst commented on Sep 3, 2021

    

    ikonst

    on Sep 3, 2021

    Contributor

    More actions

    In #10666 we've merged a variant on what @pkch's comment proposes: essentially trying to spot where boolean evaluation might done in an error (where it's not guaranteed to be meaningful), while allowing the idiomatic evaluation of e.g. strings and integers in boolean context.