global, globals(), _global ?

robert no-spam at
Wed Mar 15 12:51:57 CET 2006

Xaver Hinterhuber wrote:

> Hi Robert,
> I was using global variables some time ago, too.
> But with the time the program simply got unmaintainable, because it is very 
> hard
> to trace, why a global variable has some special value and not the one, you 
> thought it should have.
> So I redesigned the program and now I can do it without global variables.
> To me global variables are now in most cases a sign of bad design.
> Is there no other way to do it?

Yes, one should put common _application_ variables of importance to 
config instances or data-modules/classes etc.

Yet globals variables in Python are anyway "module commons". That is a 
frequent practical need.

Grep e.g. the python standard modules for use of global variables and 
use of "global "

There are many practical module globals, which control e.g. the mode of 
a module, store precomputed/cached stuff etc., and where you do not open 
an extra data structure (for now).

Most variable read-s in Python anyway go to module globals - as there 
are no other kinds of namespaces except __builtins__

( And that later scheme is fairly wonderful - compare for example the 
namespace fuzz in C/C++, Pascal, Ruby, ...  where you never know which 
module file addeds what to which namespace;

In Ruby they even scribble from anywhere to _any_ class _and_ any 
namespace without the barrier of a dot or subclassing or anything - 
using somehow by random the same name already joins!? A threat for good 
modularization of code. Not far from free flat memory programming :-) 
Don't know how they keep bigger projects managable in this language.

Yet, python module globals are set with this strange fragmented "global 
name ; name=..".

But the common storage object in question is an ordinary module anyway. 
Why not stay self-similiar and use it as such in dot-syntax for write-s 
(and often for read-s in places, where you want to express the use of a 
special global explicitly in order to not confuse things with locals, 
and want to maintain the code readable.


More information about the Python-list mailing list