C0103/N815: Constant names are not checked against UPPER_CASE naming convention

[Fall1ngStar]

Hi ruff team,

It looks like ruff doesn't check the name of constants like pylint does, despite invalid-name / C0103 (N815) being marked as done in the pylint tracking issue.

PEP 8 recommends UPPER_CASE for constant names (ref).

Example

# file.py
from typing import NamedTuple

Other = NamedTuple("Other", "a,b,c")

not_correct = "tata"
CORRECT = ""
ALSO_CORRECT = ""

def foo():
    print(not_correct)

$ pylint file.py --disable=all --enable=C0103
************* Module file
file.py:6:0: C0103: Constant name "not_correct" doesn't conform to UPPER_CASE naming style (invalid-name)

------------------------------------------------------------------
Your code has been rated at 8.57/10 (previous run: 8.57/10, +0.00)

$ ruff file.py --verbose --no-cache
[2023-02-16][12:57:12][ruff::commands::run][DEBUG] Identified files to lint in: 226.791µs
[2023-02-16][12:57:12][ruff::commands::run][DEBUG] Checked 1 files in: 7.339083ms

$ ruff --version
ruff 0.0.247

Solutions

pep8-naming N816 (mixedCase variable in global scope) already implements a weaker version of this, so I was able to adapt the code to only allow UPPER_CASE variable names in global scope, but the two rules feel a bit redundant together as some constant named thisIs_incorrect would trigger both N816 (because it is a mixed case naming) and C0103 (it does not follow UPPER_CASE convention for constants).

I guess there are 2 paths forward to solve this issue:

• Implement C0103 as a separate rule, but accept that some variable naming may trigger 2 separate diagnostics
• Modify N816 to only allow UPPER_CASE names, but this would differ from the original pep8-naming package

In any case, I would be glad to submit a PR to help get this fixed !

PS: Thanks for the awesome work you're all doing !

[charliermarsh]

I'm not sure how I want to proceed, but I found this old issue on pep8-naming: PyCQA/pep8-naming#49.

I suppose I'd be okay with implementing C0103 as a separate rule.

[Fall1ngStar]

I will work on that if that's ok !

[Fall1ngStar]

👋 Looking for a bit of guidance here, should I implement the full invalid-name from pylint ? With the checks for every type of names ? There seems to be a lot of overlap with the rules from pep8-naming so I just want to make sure that the scope for this issue is correct before I work on it 😄

[woodconn]

While there are already some N801, N802, etc. rules, it would indeed be ideal to implement the full functionality of this into it's own pylint category of rules. I'd prefer you just start with rules for the CONSTANT variable.

Ex. for "SolidNumber"
enforce-const-naming-style-UPPER (SOLIDNUMBER)
enforce-const-naming-style-snake-case (solid_number)
enforce-const-naming-CapWords (SolidNumber)
enforce-const-naming-lowercase (solidnumber)

And ideally we could use both enforce-const-naming-style-UPPER and enforce-const-naming-style-snake-case:
Meaning the constant variable would be named SOLID_NUMBER