PyMyth: Global variables are evil... WRONG!

Steven D'Aprano steve+comp.lang.python at
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> 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
> themselves.

Absolutely correct.

>> ============================================================
>>  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.

> [snip]
>> 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 
do this:

import alpha
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 mailing list