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

N815 (mixed-case-variable-in-class-scope) probably should not check TypedDict #4014

Closed
sirrus233 opened this issue Apr 19, 2023 · 2 comments · Fixed by #4066
Closed

N815 (mixed-case-variable-in-class-scope) probably should not check TypedDict #4014

sirrus233 opened this issue Apr 19, 2023 · 2 comments · Fixed by #4066
Labels
question Asking for support or clarification

Comments

@sirrus233
Copy link

Hey, thanks for writing ruff!! The following example illustrates two violations of N815, on the mixed-case variable myOtherVar. The first violation is of course appropriate. However, I think the second is misleading, and this rule should not apply to TypedDict.

from typing import TypedDict

class Foo:
    my_var: int
    myOtherVar: str  # Violation! Makes sense.

class Bar(TypedDict):
    my_var: int
    myOtherVar: str  # Violation! But shouldn't be.

A TypedDict is less of a real class, and more syntactic sugar to add typing to the keys of a dictionary. The argument here would be that if {"my_var": 0, "myOtherVar": "xyz"} would be appropriate, then the TypedDict form should be too. It may also be worth noting that the equivalent example:

Bar = TypedDict("Bar", {"my_var": int, "myOtherVar": str})

does not flag this check (although it does flag UP013, as it should).

There is a practical reason to relax the rule here: a TypedDict is a useful and lightweight way to deal with adding static typing to an untyped blob of JSON with known structure sent over the wire (say, the body of an HTTP request). The writer of the TypedDict may not have control over the structure of the untyped dict, so it becomes awkward to comply with N815 without:

  • Writing an awkward camel_to_snake parser
  • Using a functional TypedDict definition (and falling afoul of UP013)
  • Dropping a noqa on every camelCased field
  • Disabling N815
  • Using a heavier ser/de library

All of which are undesirable.

I want to point out that the current behavior of N815 does conform to the behavior of the rule upstream in pep8-naming. I'm not sure about Ruff's overall stance on modifying how rules behave, so if enforcing exact parity is important, then there probably isn't anything to be done here.

@charliermarsh charliermarsh added the question Asking for support or clarification label Apr 19, 2023
@charliermarsh
Copy link
Member

Torn on this one although I tend to agree.

@JonathanPlasse
Copy link
Contributor

Here is a non-exhaustive list of projects that would benefit from this rule.
https://grep.app/search?q=TypedDict.%2A%5C%29%3A%5Cn%20%20%20%20%5Ba-zA-Z%5D%2B%28%5Cd%5Cw%29%2A%5BA-Z%5D&regexp=true&case=true

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

Successfully merging a pull request may close this issue.

3 participants