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. -- https://mail.python.org/mailman/listinfo/python-list