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. -- \ “One of the most important things you learn from the internet | `\ is that there is no ‘them’ out there. It's just an awful lot of | _o__) ‘us’.” —Douglas Adams | Ben Finney