Will S <wsha.c...@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
_______________________________________________
code-quality mailing list
code-quality@python.org
https://mail.python.org/mailman/listinfo/code-quality
