invalid-name on TypeVar definition containing "Type" as part of the name

[leosmerling]

Bug description

for the following Generic alias declaration:

a.py

"""module a"""
from typing import TypeVar

ConfigType = TypeVar("ConfigType")

pylint issues an invalid-name warning (apparently cause the Type suffix in the name).

C0103: Type variable name "ConfigType" doesn't conform to predefined naming style (invalid-name)

According to PEP-8 https://peps.python.org/pep-0008/#type-variable-names
TypeVar should use "CapWords" naming convention, with the option of _ + suffix,
but no mention about using "Type" or not as part of the name. (I might be missing something, so please correct me if I'm wrong)

Removing the "Type" suffix from the name fixes the issue.

"""module a"""
from typing import TypeVar

ConfigObj = TypeVar("ConfigObj")

I discovered this not based on PEP-8 but mostly cause other languages using generics types allow CapWords with any content to be used generic type names (like Java, Scala, C...). I might be wrong but I hope this helps clarifying the issue.

Configuration

No response

Command used

pylint a.py

Pylint output

************* Module a
a.py:4:0: C0103: Type variable name "ConfigType" doesn't conform to predefined naming style (invalid-name)

Expected behavior

No warning for correctly CapWord cased TypeVar.

Pylint version

pylint 2.13.2
astroid 2.11.2
Python 3.9.7 (default, Sep 16 2021, 13:09:58) 
[GCC 7.5.0]

OS / Environment

PopOS/Ubuntu:
Linux 5.16.11-76051611-generic #202202230823164624826121.10~2b22243
Wed Mar 2 20: x86_64 x86_64 x86_64 GNU/Linux

Additional dependencies

No response

[cdce8p]

You're correct that PEP 8 only mentions CapWords. However, we deliberately chose to forbid the Type suffix. The reason was that it felt more like a TypeAlias that way. To make the distinction clear, it's better to suffix TypeVars with T.

I.e. ConfigTypeT. You can find some more examples here.

[leosmerling]

Thanks for the clarification. Then I assume I can adopt this convention in my code and this issue can be closed (at least from my point of view I don't have a strong opinion in favor or against it)

[mwgamble]

It would be great if the messages users see when encountering errors like this were more helpful. A message like this:

Type variable name "StatusType" doesn't conform to predefined naming style

Is incredibly unhelpful. It doesn't tell me what the predefined naming style is, nor where to find out what it is. It doesn't even explicitly tell me what is wrong with the name that has been chosen, despite the fact that forbidding the Type suffix was apparently a conscious decision.

[Pierre-Sassoulas]

I agree @mwgamble we have #6053 opened for this.

[Lx]

You're correct that PEP 8 only mentions CapWords. However, we deliberately chose to forbid the Type suffix. The reason was that it felt more like a TypeAlias that way. To make the distinction clear, it's better to suffix TypeVars with T.

I.e. ConfigTypeT. You can find some more examples here.

Updated URL for referenced doc:
https://pylint.pycqa.org/en/latest/user_guide/messages/convention/invalid-name.html#predefined-naming-patterns