--strict-boolean allows logical not to be applied to non-booleans

[pkch]

a: str

if a:  # Condition must be a boolean
    1

if a and True:  # Condition must be a boolean
    1

if not a:  # No error
    1

The third if statement should also get the same error message.

[gvanrossum]

IMO the fix is to get rid of --strict-boolean. It is unPythonic. :-)

[pkch]

And, you're not even joking!! :) If I'm the only one using it, we should seriously get rid of it to lower maintenance.

[gvanrossum]

That needs to be negotiated with the OP who requested it and implemented it. Can you do a git blame/log to figure out who that was and which PR(s) to use to reach them?

[gvanrossum]

Oh, the blog post says it's Alex Frieder. @afrieder see comments ^^.

[afrieder]

I just implemented it on someone else's request. If people aren't using it I'm perfectly fine with reverting the commits.

[gvanrossum]

We should at least ask that person if they use it. IMO it makes --strict (which implies it) less useful, since nobody writes code that conforms to --strict-optional except people expecting Java.

[gvanrossum]

The original request is #1730 and the OP is @tigrfhluerh. See ^^

[Herst]

As mentioned in Gitter, I had a use case for it where I would temporarily enable it in order to find potential places where explicit is [not] None checks would be more appropriate, e.g. the return values of re.match()/re.search().

[gvanrossum]

Hm, but a successful result of those types is never falsey.

[Herst]

Exactly, which is why checks like if not reMatchReturnVal: can be changed into if reMatchReturnVal is not None: and this what I used or rather repurposed --strict-boolean for.

[gvanrossum]

Eek. That looks worse than the original and surely there is no measurable speed-up even if that was all you did in a tight loop.

Let's close this and instead start a new issue "Drop --strict-boolean".