PyMyth: Global variables are evil... WRONG!

[Rick Johnson]

On Wednesday, November 13, 2013 11:50:40 PM UTC-6, Steven D'Aprano wrote:
> On Wed, 13 Nov 2013 19:45:42 -0800, Rick Johnson wrote:
> > On Wednesday, November 13, 2013 8:45:16 PM UTC-6, Steven D'Aprano wrote:
> >>  A fully-auto machine gun with a hair-trigger and no
> >> safety is no  different from a single-barrel shotgun with a safety and
> >> a trigger lock!  You can blow your foot off with both!
> > Yes. But in the case of the shotgun you'd have to find the key, unlock
> > the trigger, unset the safety, and aim REALLY well... because your only
> > getting off one shot, and if you miss or only wound me, i've got that
> > full auto machine gun with hair trigger and no safety -- i won't need to
> > live very long to return the favor. >:)
> I think you're missing the point that we're talking about the coder 
> shooting themselves in the foot, not Gunfight At The OK Corral. There's 
> no "favour" to return. 

And you missed the point that i took your straw-man and
converted him into satire. You owe me gratitude for
*politely* ignoring your repeated logical fallacies.

> Yes, the point is that process-wide global variables are
> demonstrated by 50+ years of programming experience to be
> best avoided (in general -- there are caveats and
> exceptions of course). We're talking about probably
> millions of person-hours of experience leading to the
> conclusion that "globals are harmful".

But yet Python has globals, you just have to *import* them.
But that design is flawed

> It isn't that global variables will leap out of the
> computer and attack you while you sleep,

Funny, that sounds like my argument from earlier. Something
about "gremlins".

> of course, but that in general *its too damn hard* for
> human programmers to write good, reliable, maintainable,
> correct (i.e. bug-free) code using process-wide global
> variables.

Complete FUD. Maybe for you. Not for me.
 
> Global variables are the spaghetti code of namespacing --
> everything is mixed up together in one big tangled mess.

It's a tangled mess if you design it to be a tangled mess. 

> The more global variables you have, the worse the tangle. 

Complete illogic. 

What if all the globals are only accessed
and never mutated? You could have a million globals that never
change (of course they'd technically be constants) and never
suffer a single error from globals EVEN IF your an incompetent
software designer.

> One or two is not too bad. With good conventions for
> encapsulation to limit the amount of tangled, coupled code
> (e.g. naming conventions, or limiting globals to a single
> module at a time by default) the amount of harm can be
> reduced to manageable levels.

> SO now your agreeing that globals are not evil again. I
> positied an anaology in a passed thred that went something
> like this:

ManufacurerA claims his car is the safest on the road.

ManfacturerB drives ManfacturerA's car into a ditch and then
claims ManfacturerA is a liar.

Result: Who is wrong?

> Global variables increases coupling between distant parts
> of the code. I remember a nasty little bug in Windows
> where removing IE stopped copy-and- paste from working
> everywhere. That's a sign of excess coupling between code
> -- there's no logical reason why removing a web browser
> should cause copying text in Notepad to fail.

Do you have link describing this bug? I am not aware of such
bug ,but uh, i would not at all be surprised that windows
could break from removing that gawd awful IE.

Come to think of it, i'll bet it's not even a bug at all,
but a feature to prevent "wise users" from removing IE,
thereby maintaining IE's footprint in the wild. 

Steven, this sounds more like Fascism than "clumsy use of
globals" to me.

But even IF globals are to blame, by removing IE, you have
removed a large chunk of code from a code base that was not
designed for modularity. (We could argue whether or not
windows should allow removal of IE, but ultimately that is
M$ decision)

No developer could possibly forecast every possible "bad
thing" a user might decide to do. Especially when we're
talking about ripping components of the software out
completely.

Do i think IE should be a removal component? HECK YEAH, and
i would have designed it that way. But IS is not my baby, it
belongs to Mr. Gates, and he designs his software any way he
damn well pleases, and you and i can choose not to use it.

Image if someone downloaded Python and just started ripping
out source files willy-nilly because they did not like them
for whatever reason. Then, they came to this list and start
bitching because Python was blowing chunks. And don't give
examples of things that can be ripped out without breaking
Python, because that is germane either.

How would you respond to such complaints? 

Hmm...never thought you'd be agree with Mr. Gates did ya?

> We want to avoid unnecessary coupling: opening your fridge
> door shouldn't flush the toilet.

*KAH-BOOM* (Straw-bomb expodes)(AGAIN!)

> Since global variables increase coupling, and coupling is
> often harmful, one way to avoid unnecessary coupling is to
> avoid unnecessary global variables.

Nice! Your attempts to posit that "harmful coupling" is the
almost unavoidable outcome of "globals" is not fooling me.
Here's another way to phrase:

    Since transportation increases chances of death or
    injury from accidents, and death or injury is often
    harmful, one way to to avoid unnecessary death or injury
    is to avoid transportation.  
    
There are two logical ways to react to such grim reality:

    We could become consumed with fear and destroy all motor
    vehicles, bicycles, skateboards, etc...  and instead
    adopt the locomotion of our forefathers by utilizing our
    feet. or,
    
    We reduce the risks to almost nothing by designing and
    implementing globals via a logical and consistent
    interface. Then, to be sure, we test religiously
    (psst:we should be doing this anyway!!!)
    
But what we don't want to do is lull ourselves into a false
sense of security by "hiding" globals behind a pseudo
interface and thinking we have solved the problem of
globals. 

And this is what Python modules are doing! 

No, you've solved nothing. All you've done is to
stick you head in the sand.

============================================================
 It's my code, my problem, not yours!
============================================================    

Yes, you are correct. 

If you want to go on using globals in a dangerous way, or
using module attributes and believing falsely they're not
global, then by all means go on. HOWEVER, don't infect the
world with your sloppy architecture. KEEP YOU CODE TO
YOURSELF!

But that's not the case is it, NO, many of you are infecting
Python's code base with horrible code. 

Python's warts are *really* exposed when Python is embedded
as a scripting language. Since multiple scripts from
multiple authors will be running under the same process, any
one of them can bring the whole house of cards crashing
down. And with Python's current design, that possibility is
more likely.

It's sad, because Python is a great choice for scripting,
but the major design flaws are self defeating. Even
the best syntax ever created cannot make up for such
illogical inconsistencies at the core.

> Think of them as leaches. [snip remaining straw-bombs]