N815: Ignore TypedDict class variable casing

[danielpatrickdotdev]

Prosed fix for #178

Add specific exemption from N815 for all subclasses of TypedDict because class variable naming conventions should not apply to dictionary keys.

I've tried to reuse code from the rule for Exceptions (N818) as per the suggestion on #178.

This is my first time working with the ast module or with any flake8 plugin so please bear that in mind when reviewing this PR. Any advice on whether it's reasonable to tag every ClassDef with the names of its superclasses, and potential performance concerns around that, would be very welcome. On balance, I thought it may be preferable to do this rather than determining the superclasses again for every variable in a class.

Thanks :)

[danielpatrickdotdev]

Whilst this approach covers many scenarios, I can't see an easy way to handle mutliple layers of inheritance from TypedDict across modules. If anyone has any thoughts on that I would appreciate it!

[sigmavirus24]

Why are we skipping this altogether? People may in fact want to check this. I would instead think we should add an error code for this case so it can be ignored/disabled on a case-by-case basis

[danielpatrickdotdev]

Good question. Happy to have a go at implementing that. Would you go with something like N819: mixedCase variable in TypedDict? Do you think we should disable by default?

[danielpatrickdotdev]

Have pushed a new commit to implement this new error code, let me know what you think

[sigmavirus24]

Whilst this approach covers many scenarios, I can't see an easy way to handle mutliple layers of inheritance from TypedDict across modules. If anyone has any thoughts on that I would appreciate it!

We can't handle that at all. To do so would require running the code to get the __mro__ at runtime. As this is purely static analysis, we can't build that ourselves - it's too complex. We already have plenty of cases where we might otherwise want to ignore things like this and can't handle it for this exact same reason

[danielpatrickdotdev]

We can't handle that at all. To do so would require running the code to get the __mro__ at runtime. As this is purely static analysis, we can't build that ourselves - it's too complex. We already have plenty of cases where we might otherwise want to ignore things like this and can't handle it for this exact same reason

I suspected as much but wasn't sure of what a solution might involve. Thanks