PyMyth: Global variables are evil... WRONG!

Rick Johnson rantingrickjohnson at gmail.com
Mon Nov 11 21:06:09 EST 2013


PyMyth: Global variables are evil... WRONG!

============================================================
 Python's Global Hysteria:
============================================================
How many times have your heard or read the phrase: "Global
variables are evil"? Well if you've been a member of the
Python community, I'll bet you've heard or read it more than
most other community members.

In this thread, i want to get to the bottom of this whole
"global-phobia" thing once and for all, and hopefully help
you folks understand that globals are not all that bad --
when DESIGNED and USED correctly that is!

============================================================
 The denial of the 99%:
============================================================
Python has globals, but we just can't admit it!

The creators thought they would prevent the little
"PyPeople" from hurting themselves by "handicapping" our
globals in the form of "module level" globals.

But even the "module level" globals can be accessed
"globally" if the module they are contained in is imported
everywhere.

    import glomod
    glomod.var # Access
    global.var = newValue

Which leads me to the conclusion that the designers were
either naive or underestimated the chutzpah of this fine
community.

============================================================
 The Power of the 1%:
============================================================
Most of this "fear of globals" can be traced back to a
minority of naive coders who used globals haphazardly and
were hurt by them, <sarcasm>and now we ALL have to suffer
because future idiots need to be protected from themselves!
</sarcasm>

Too many times I've seen idiotic uses for globals.

One more atrocious example was "dialog return values" stored
as globals so the "dumb coder" could eaisly restore the
previous state of the dialog values between successive
calls.

Obviously the best solution would be for the dialog object
ITSELF to store (and restore) the values when necessary, but
alas, here i am again expecting people to create interfaces
that are consistent and logical. *rolls-eyes*

Of course we can only blame the dialog designer and not the
caller for this design flaw, but the caller still has no
excuse for globally storaging these values.

If the caller cannot repair the mistake by extending the
dialog object himself, then he can store the values within
the current module or class level scope. There is no excuse
for elevating this information to global scope.

However, there ARE justified uses of global variables!

============================================================
 Justifying Global Variables:
============================================================
Globals are justified when they are used to communicate
information between scopes that otherwise were meant to be
mutually exclusive. One good example would be package sub-
modules.

Now. Some might believe that the purity of namespaces
becomes tainted if they can be violently penetrated by
global variables. But again, they are falling back on gut
reactions fostered from years of brain washing. Yes, globals
can be bad (if misused), but for the most part they are
crucial to transferring information CLEANLY between isolated
namespaces

But even globals themselves are not good enough UNLESS we
engineer a "global hierarchy"!

============================================================
 From Flat to Nested == From Tricked to Bested:
============================================================
One of the shortcomings of the current implementation of
global variables is their inherent "flat" access nature.
There is no hierarchy of globals, and once all the good
names are taken, your screwed!

 "But Rick, even when we use globals, we don't need that many"

Only if you consider the single package that represents your
program, but what about the thousands of support libraries
with millions of lines of code that work in the background
to make your measly few thousand lines of code work?  What
about all the globals that they have injected?

 "Never thought of that really"

Throwing out global names UNADORNED is folly. Could you
imagine telephone numbers without area codes?

 Hmm: Am i calling "Jim" in Beverly Hills California???

   california.beverlyhills.jim

 or "Jim" in "Spokane Washington"???

   washington.spokane.jim

You see, you need to QUALIFY these names not only to make
then unique, but also so the caller will understand who he
is calling.

Same goes for globals.



More information about the Python-list mailing list