-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docparams check doesn't understand class hierarchies #4955
Comments
@Pierre-Sassoulas I would like to give it a try. My current idea is to enhance pylint/extensions/_check_docs_utils.py::possible_exc_types to not only return the names of the exceptions, but the whole exception hierarchy. Or, as an alternative, it can return a set of nodes instead of strings to check later the hierarchy. But, I currently struggle to get the super class of a given exception class. Any idea? |
I think ClassDef nodes in astroid have a parents or ancestor attributes. You can check the doc or the astroid code directly to confirm. |
@Pierre-Sassoulas thanks a lot. Found it. By any chance, do you know why I already removed the type and ran |
I don't know, you could try to check the git history of this particular line. See https://stackoverflow.com/a/19757493/2519059 |
Already done. I found the commit adding it but there was no explanation why this is needed. Let me further check |
Before, missing-raises-doc could not understand class hierarchies but just compared names. So, when a method documented a raise of a parent class, but a child exception was raised, the check failed. With this change, if the name compare doesn't help, the exception class hierarchy is checked. For that, possible_exc_types was changed to return classes instead of names Resolved #4955 Co-authored-by: Pierre Sassoulas <[email protected]> Co-authored-by: Daniël van Noord <[email protected]>
Bug description
Configuration
No response
Command used
Pylint output
Expected behavior
No error;
I understand that checking the hierarchy is more complicated, but I guess there are valid use cases to expose only a general exception
Pylint version
OS / Environment
Linux
Additional dependencies
No response
The text was updated successfully, but these errors were encountered: