Skip to content
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

Open
gaborbernat opened this issue Sep 15, 2021 · 10 comments
Open

TypedDict classes should be exempt from N815 #178

gaborbernat opened this issue Sep 15, 2021 · 10 comments

Comments

@gaborbernat
Copy link

class Key(TypedDict):
    stepId: str  # noqa: N815
@sigmavirus24
Copy link
Member

We don't special case anything like this except what we default --ignore-names to. That would likely be the best place to configure this.

@gaborbernat
Copy link
Author

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.

@sigmavirus24
Copy link
Member

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 unittest methods that are part of the default --ignore-names wouldn't be there but would be part of an exclusion applied to any class that inherits from unittest.TestCase.

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 TypedDict, we aren't going to be able to detect that. We don't follow imports today, we don't want to (it adds significant time, fragility, and complexity - see also openstack's "hacking" plugin), and we'd still end up with issues like this.

@gaborbernat
Copy link
Author

gaborbernat commented Sep 15, 2021

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.

@jparise
Copy link
Member

jparise commented Sep 16, 2021

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 Exception subclasses.

def get_classdef(cls, name, parents):
for parent in parents:
for node in parent.body:
if isinstance(node, ast.ClassDef) and node.name == name:
return node
@classmethod
def superclass_names(cls, name, parents, _names=None):
names = _names or set()
classdef = cls.get_classdef(name, parents)
if not classdef:
return names
for base in classdef.bases:
if isinstance(base, ast.Name) and base.id not in names:
names.add(base.id)
names.update(cls.superclass_names(base.id, parents, names))
return names

A path to implementing the suggestion in this issue might be:

  • Generalize the code above
  • Introduce an ignore-class-names (or similar) configuration option which skips all (or a subset of?) checks for matching subclasses
  • Consider defaulting the list of ignored class names to ["TypedDict"]

@danielpatrickdotdev
Copy link

Since TypedDict is a special case, and this is much simpler to implement than adding a new option, I've raised #189 as a proposal to address that specific case

@sigmavirus24
Copy link
Member

--ignore-class-names fixes the problem of wanting to understand inheritance across modules, @danielpatrickdotdev, because we can't handle that otherwise as you rediscovered in #189.

@danielpatrickdotdev
Copy link

--ignore-class-names fixes the problem of wanting to understand inheritance across modules, @danielpatrickdotdev, because we can't handle that otherwise as you rediscovered in #189.

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

@sigmavirus24
Copy link
Member

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.

@danielpatrickdotdev
Copy link

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 --ignore-variable-names-for-subclasses. Even that mouthful doesn't quite capture it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants