You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
--strict-boolean allows logical not to be applied to non-booleans #3185
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?
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.
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().
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.
Activity
gvanrossum commentedon Apr 18, 2017
IMO the fix is to get rid of
--strict-boolean. It is unPythonic. :-)pkch commentedon Apr 18, 2017
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 commentedon Apr 18, 2017
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 commentedon Apr 18, 2017
Oh, the blog post says it's Alex Frieder. @afrieder see comments ^^.
afrieder commentedon Apr 18, 2017
I just implemented it on someone else's request. If people aren't using it I'm perfectly fine with reverting the commits.
gvanrossum commentedon Apr 18, 2017
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-optionalexcept people expecting Java.gvanrossum commentedon Apr 18, 2017
The original request is #1730 and the OP is @tigrfhluerh. See ^^
Herst commentedon Apr 19, 2017
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] Nonechecks would be more appropriate, e.g. the return values ofre.match()/re.search().gvanrossum commentedon Apr 19, 2017
Hm, but a successful result of those types is never falsey.
Herst commentedon Apr 19, 2017
Exactly, which is why checks like
if not reMatchReturnVal:can be changed intoif reMatchReturnVal is not None:and this what I used or rather repurposed--strict-booleanfor.gvanrossum commentedon Apr 19, 2017
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".