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
I had a few thoughts for some more linter checks I'd like to have. Would be happy to implement them here if you guys are interested.
1. return <value> or yield <?from> <?value> in __init__()
Example:
classExample:
def__init__():
return1# badyield# badyield1# badyieldfrom () # badreturn# ok
Any returning of values, or yielding, in an __init__() would result in a runtime error, but not until you try to instantiate an object of the class. So I think this should be a reasonably safe on-by-default error.
2. assert <constant or fixed value>
Normal asserts:
assertconditionassertcondition, "message"
There's already a flake8 check for asserting on a tuple specifically - e.g. accidentally adding parens around (condition, message). And there's a bugbear check for assert False warning that it's disabled by -O. But forgetting the condition (assert "message") or asserting on any other literal value or list/tuple will either always pass or always fail - and is probably unintentional?
3. Inconsistent returns in function
deffunc(x) ->int|None:
ifx:
return0# should return None here
This one's more opinionated, but if a function returns something in some case, it should explicitly return something (None) in all other cases.
The text was updated successfully, but these errors were encountered:
Thanks for asking before spending the time on the PR and us potentially saying nope.
I'd accept it - Thought I do feel cpython/implementations should error on this
I'd accept it ... Anything that is usless / pointless and not covered by a more specific flake8 plugin is welcome here
With this one, are you only checking that there is always explicit returns at the end of a function's body? You're never worrying about the type right as I feel mypy / other type checkers will get that.
If so, I'd accept that too.
I don't feel the need for any of these to be optional. They all seems sane to me. But would love another contributor or users views ...
3 is probably better left to a type checker; mypy already has a similar check. In general, it requires type information to know whether a function always returns. Some examples:
I had a few thoughts for some more linter checks I'd like to have. Would be happy to implement them here if you guys are interested.
1.
return <value>
oryield <?from> <?value>
in__init__()
Example:
Any returning of values, or yielding, in an
__init__()
would result in a runtime error, but not until you try to instantiate an object of the class. So I think this should be a reasonably safe on-by-default error.2.
assert <constant or fixed value>
Normal asserts:
There's already a flake8 check for asserting on a tuple specifically - e.g. accidentally adding parens around (condition, message). And there's a bugbear check for
assert False
warning that it's disabled by-O
. But forgetting the condition (assert "message"
) or asserting on any other literal value or list/tuple will either always pass or always fail - and is probably unintentional?3. Inconsistent
return
s in functionThis one's more opinionated, but if a function returns something in some case, it should explicitly return something (
None
) in all other cases.The text was updated successfully, but these errors were encountered: