PyMyth: Global variables are evil... WRONG!

Rick Johnson rantingrickjohnson at gmail.com
Thu Nov 14 04:22:02 CET 2013


On Wednesday, November 13, 2013 7:09:42 PM UTC-6, Steven D'Aprano wrote:
> On Wed, 13 Nov 2013 23:42:24 +0000, Rhodri James wrote:
> > On Tue, 12 Nov 2013 02:06:09 -0000, Rick Johnson wrote:
> >> 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  claim that Python has no globals.
> That would be a stupid thing to say for a language with a
> "global" keyword, 

Yeah, a "global" keyword that extends access ONLY as far as
module level scope -- hardly a *true* global.

> a "globals" function, 

Yeah, a "globals function" that returns the MODULE LEVEL
globals symbol table.

> and a built-in module that is shared across the entire
> process.

Now your thinking clearly. This is where Python's dirty
little "secret globals" live.

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

Oh lord, back to the fuzzy logic again :(
 
> It just means that attribute access on the module object
> is the supported interface for manipulating names in
> namespaces which are modules.

HUH? Was this last sentence an attempt to distract? We are
all quite aware that DOT access is the interface for
accessing module members, but what the hell does that have
to do with "process wide globals"?

No, your not going to so easily fool this audience with
slight of hand! In your generalized code example:

    import alpha
    alpha.spam = 23
    
Yes. "spam" is an attribute of module "alpha", however, it is
also a global variable. Why?
 
  BECAUSE "alpha.spam" CAN BE MUTATED FROM ANYWHERE!

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

Here you go again. Steven, we are ALL quite aware of these
facts, how is "setattr" germane to my complaints about globals?

> Since manipulating attributes is useful, a philosophy of
> consenting adults applies and we have direct access to
> those attributes, 

We don't have "direct access", but access is an import away.

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

Yes we must be careful, because these attributes are
ACTUALLY global. The fact that you have to use an import
statement to reach them does not alter the fact that they are
globally mutable.

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

Exactly. That's why globals should be used intelligently.
There are many methods of creating an intelligent ordering
of global names so they don't clash. One of the most
simplistic is to tag all names with a prefix.

The best method is to have a namespace for globals that is
available everywhere WITHOUT import and accessed via a
single letter (you could emulate this now in Python by
injecting a namespace into sys.modules). In this manner,
globals will be both easily accessible, qualified (no need
for prefixes), and available WITHOUT messy imports

> But that's not the case here: alpha's "spam" is separate
> from module omega's "spam" variable. To give an analogy:
> [snip analogy]

Steven you're going off into "la-la land" man. Are you
suggesting that because two modules can contain the same
name that module attributes are not global?

I love how you support the duck typing paradigm UNTIL it
interferes with your argument. Sure, under Python's current
implementation of "globally mutable module attributes" you
can have the same name stored in different modules all with
different values, but they're still GLOBALS!

Because I can reach in and access them OR mutate them from
ANYWHERE! That's the very definition of a "globally
accessible variable" (aka: global variable)

    AND THIS IS WERE THE HYPOCRISY COMES IN. 
    
Since python modules have no set/get interface restrictions,
ALL attributes are globals!





More information about the Python-list mailing list