PyMyth: Global variables are evil... WRONG!

[Tim Daneliuk]

On 11/11/2013 10:46 PM, Rick Johnson wrote:
> On Monday, November 11, 2013 8:47:09 PM UTC-6, Tim Daneliuk wrote:
>> I think this is certainly the use case most people would
>> suggest. But I think you may have missed the real reason
>> most modern designers object to inter-module globals:  The
>> presence of such entities almost always means the code has
>> been designed badly.  Whether we're writing pristine OO
>> code (cough, cough) or more traditional procedural stuff,
>> information hiding is a good thing.
>
> Yes, and i agree. But you cannot "hide" everything. There
> will always be a need to share information.
>
>> When and where there is a need for modules (or programs,
>> or machines, or "clouds", or interstellar space ...) to
>> share information, my view is this is better done via some
>> sort of interface/message passing mechanism.
>
> But python modules can't be interfaces because interfaces
> should protect internal data, prevent external forces from
> meddling with internal state (EXCEPT via the rules of a
> predefined "contract"), hide dirty details from the caller,
> and have clearly defined access points.
>
>    BUT PYTHON MODULES DON'T FOLLOW THIS DESIGN PATTERN!


I think this is an unfair criticism.   You can do this in
ANY language if you know how.  For example, if I understand
stack frames, I can write code that fiddles with local
variables in compiled code.  For that matter, if I understand
pointers at the assembler level, I can probably do the same
with globals.

Global access/visibility is a matter of convenience - it's harder
to do in a static compiled language and easier to do in a
late bound, dynamic language.   The fact that this is
*possible* in Python doesn't speak to Python's fitness for
any particular purpose nor does it speak to whether globals
are a good- or bad idea.  Anyone that knows enough to fiddle
with the internal implementation of a module and or subvert
global constants like math.pi, also know what they're doing
is "perverse" and have to be willing to live with the side
effects and consequences of such acts.

I cut my teeth in this business writing realtime machine control
software in assembly language (and PL/M!) where there was NO
memory protection and everything - code, data, stack - was
"global" in some sense, or at least could be made to be.
We managed to routinely write highly reliable, blazingly
fast code that didn't break, didn't bork, and did what it
was supposed to.   There's no reason to believe that Python
programs cannot do the exact same thing (well, not the realtime
part) with just as much robustness and correctness as those
old asm programs.

Programming well has far less to do with the language and has
far more to do with the designer and coder...


----------------------------------------------------------------------------
Tim Daneliuk     tundra at tundraware.com
PGP Key:         http://www.tundraware.com/PGP/