Global Variables in OOP and Python

[Kay Schluehr]

Steven D'Aprano wrote:
> On Fri, 30 Dec 2005 20:00:51 -0500, Mike Meyer wrote:
>
>
> >> The other way I thought of is to create a separate class that consists
> >> of the variables and to use the
> >>
> >> from <file name> import *
> >>
> >> in all of the files (namespaces) where it is needed.
> >
> > Except for one detail, this is a Pythonesque method. The detail is
> > that "from <module> import *" is generally considered a bad
> > idea. There are two reasons for this:
>
> Agree about from module import * being bad, but it is still generally poor
> practice for the same reason using global variables is generally poor
> practice.

No, I don't think so. The general wisdom is that global variables are
bad not because they are global, but because they are variable.
Responsibility about state mutation is scattered across the code and
spaghetti is the likely consequence. This cannot be prevented by
changing the access protocoll ( getters / setters ) or using static
variables. Mutable OO-singletons are not less harmfull than good old
globals.

Namespace pollution or name clashes are another issue and we have to
make a tradeoff between easeness of following references and namespace
security on the one hand conciseness on the other. I'm not completely
unhappy using "True" instead of  "__builtins__.True" allthough the
latter would be more pure.