PyMyth: Global variables are evil... WRONG!
steve+comp.lang.python at pearwood.info
Thu Nov 14 02:09:42 CET 2013
On Wed, 13 Nov 2013 23:42:24 +0000, Rhodri James wrote:
> On Tue, 12 Nov 2013 02:06:09 -0000, Rick Johnson
> <rantingrickjohnson at gmail.com> wrote:
>> PyMyth: Global variables are evil... WRONG!
> That's not a PyMyth. It's a CompSciMyth, or to be more accurate a good
> general Software Engineering guideline regardless of language.
To be precise, it's not a myth at all.
Just because there are occasional medical uses for digitalis doesn't make
it a myth that it is deadly poison. Just because there are occasional
programming uses for global variables doesn't make it a myth that they
are poor practice and lead to hard-to-maintain, unsafe, buggy code.
> Like all
> guidelines it can be broken, but people who break it should do so
> knowingly, aware that they have created potential problems for
>> The denial of the 99%:
>> ============================================================ Python has
>> globals, but we just can't admit it!
> A different subject entirely, but no more accurately stated.
Completely inaccurately stated. It certainly isn't true that "99%" of
people (who exactly? Rick doesn't say) claim that Python has no globals.
That would be a stupid thing to say for a language with a "global"
keyword, a "globals" function, and a built-in module that is shared
across the entire process.
>> But even the "module level" globals can be accessed "globally" if the
>> module they are contained in is imported everywhere.
> Remember when I said that guidelines can be broken?
I think you know the following, but for anyone else reading...
Just because a module global alpha.spam is accessible to anything that
imports the module doesn't make it a process-wide global. The ability to
alpha.spam = 23
does not make "spam" a process-wide global. It just means that attribute
access on the module object is the supported interface for manipulating
names in namespaces which are modules.
There is very little practical difference apart from convenience between
directly manipulating attributes as above, and using a setter function
like "setattr(alpha, 'spam', 23)". Python tries to avoid boilerplate.
Since manipulating attributes is useful, a philosophy of consenting
adults applies and we have direct access to those attributes, with an
understanding that we should use this power with care. With great power
comes great responsibility -- if you're going to reach inside another
module and manipulate things, you ought to know what you're doing.
One of the numerous problems with process-wide globals is that there's no
encapsulation and consequently one package's use of "spam" clobbers
another package's use of "spam" for a different purpose. But that's not
the case here: alpha's "spam" is separate from module omega's "spam"
To give an analogy: just because I can walk through the door of number 23
Alpha Street and rummage through their fridge, and walk through the door
of number 42 Omega Road and do the same, doesn't mean that the two
fridges are actually the same fridge.
More information about the Python-list