I am trying to understand why pylint treats module-level global variables as constants when checking the validity of their names. I though pylint followed PEP8 but if I look here: https://www.python.org/dev/peps/pep-0008/#id42 I see that global variables should follow the same format as function names (with some caveats about beginning with a "_" or being protected by __all__).
Is the problem that it is difficult to determine whether a module-level variable is a constant or a global variable, so it was decided to err on the side of constants since use of global variables is generally discouraged and the invalid-name check can be locally disabled for the few global variables that are needed?
Will
Will S wsha.code@gmail.com writes:
I am trying to understand why pylint treats module-level global variables as constants when checking the validity of their names.
One thing to realise is that this is a case where the term “variable” doesn't really help us. The language only knows that it's a name bound to an object. The concept “variable versus constant” is not a concept that's enforcible in Python.
Public module-level names should be either code objects, or constants. Module-level names that are not constants or code objects, should be implementation-only and therefore should be named with a leading underscore for use only within the module.
This is an implication from PEP 8:
Global Variable Names
(Let's hope that these variables are meant for use inside one module only.)
URL:https://www.python.org/dev/peps/pep-0008/#global-variable-names
Is the problem that it is difficult to determine whether a module-level variable is a constant or a global variable
Partly, yes: Python quite deliberately doesn't have a way for defining unmodifiable name bindings, so “constant” is only a social convention.
Mostly, though, it's an opinion expressed in the style guide: Don't make a name part of the public API unless it's a code object (a function or class), or a constant.
-
Ben Finney -
Will S