-
Notifications
You must be signed in to change notification settings - Fork 206
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
TypedDict classes should be exempt from N815 #178
Comments
We don't special case anything like this except what we default |
I don't consider it a viable option, clearly, in this case, the PEP shouldn't mandate, and I don't think having to allowlist every name one by one is the path ahead. Also, I don't want these names to show up outside of a typed dictionary. So let us reconsider please. |
We would need significant refactoring to say "Ah, this has inherited umpteen times from a TypedDict and yes it's that TypedDict" which to handle 1 attribute here isn't reasonable. If we had anything like that, the The part where this becomes especially difficult is where we don't execute code we statically analyze it, so if someone inherits from some 3rd party library class that inherits from |
I wasn't thinking to cover 100% of the cases but feels like covering the most common case (direct inheritance) as a low hanging fruit with a big benefit. It's fine e.g. to say we don't support typed dict definitions across files. |
We actually now have code that attempts to traverse as much of the class hierarchy as is possible (given the AST's limitations). We use it to find pep8-naming/src/pep8ext_naming.py Lines 300 to 316 in 9adbbc4
A path to implementing the suggestion in this issue might be:
|
Since |
|
It does, but I'm never keen on blanket ignores like that, so was hoping for something more precise. I can live with something that covers common cases though |
Having a list of class names is far more precise than blanket ignoring any TypedDict inherited class which may or may not have non-snake-case attributes. |
In some ways it is, but it's quite an unweildy thing to define. I certainly wouldn't want to ignore all checks for a list of classes. Plus in this case we're interested in superclass names. I ended up with |
The text was updated successfully, but these errors were encountered: