[code-quality] Valid global and constant names

[Ben Finney]

Will S <wsha.code at 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