Expand variable name type to include non-constant, module-level variables

[mdepp]

Is your feature request related to a problem? Please describe

Naming style of module-level non-constant variables is not enforced. For example,

helloWorld = True  # should be HELLO_WORLD; caught as `invalid-name` message
goodbyeWorld = {}  # should be goodbye_world; not caught by pylint

My best guess for the reason is that non-constant module-level variables do not fall into any name type. Prior to pylint 2.5.0 they counted as const. This was fixed in 3422e4a, but now there are no naming style checks at all for these variables.

Describe the solution you'd like

Expand the variable name type to include non-constant module-level variables. Alternatively, define a new name type specifically for non-constant, module-level variables.

Additional context

[Pierre-Sassoulas]

The fix is "easy", I have something locally. But there would be false positive as soon as pylint make a mistake on the inference of a constant. Also it broke 53 tests in the test suite most of them functional, For example:

TESTLIST = [1, 2, 3] # now raise [invalid-name] should be test_list
TESTTUPLE = (1, 2, 3)  # now raise  [invalid-name] should be test_tuple
TESTSTR = '123' # constant, so an OK name

Or :

j = 4; LAMB = lambda x: x+j  #  now raise [invalid-name] should be lamb ?

FUNC4 = lambda a, b: a != b  #  now raise [invalid-name] should be func_foor ?

I use constant that are mutable sometime, and variable that are immutable. So I don't know, about this one. Maybe a test that this is UPPER_CASE or snake_case but not something else ? In fact for logger vs LOGGERI've seen both usage in big python code base, so having a warning for this seem opinionated.

[mdepp]

Checking for either UPPER_CASE or snake_case makes sense to me. Really I just want to prevent mixedCase from showing up in globals... Maybe the best solution is to create a new name type then.

[Pierre-Sassoulas]

Closing as a duplicate of #3585