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
As pointed out in #215 and #217, overridden method names are out of the dev's control when subclassing an external library.
But that actually extends to the whole method signature. Renaming a method parameter in a subclass breaks LSP, so I believe ignoring it in these cases would avoid inducing the user to a bad practice.
fatalError is not positional-only, so renaming it to fatal_error would cause an error if the method was called as feedback.reportError("oh no", fatalError=True) somewhere else.
The text was updated successfully, but these errors were encountered:
On second thought, maybe ignore N803 but leave N804/N805 as they are?
Considering a first parameter not called self/cls seems less likely on third-party libraries, it could actually just be a mistake on the user's side.
On the rare occasion it's actually necessary to ignore these warnings, it seems OK to just #noqa them, which would also signal to a reader who knows pep8-naming: "hey, see that odd-named first parameter? It should be self/cls, but there's nothing I can do about it because I don't own the base class".
As pointed out in #215 and #217, overridden method names are out of the dev's control when subclassing an external library.
But that actually extends to the whole method signature. Renaming a method parameter in a subclass breaks LSP, so I believe ignoring it in these cases would avoid inducing the user to a bad practice.
Example using QGIS Python API:
fatalError
is not positional-only, so renaming it tofatal_error
would cause an error if the method was called asfeedback.reportError("oh no", fatalError=True)
somewhere else.The text was updated successfully, but these errors were encountered: