Antoon Pardon wrote: > Op 17-08-13 17:01, Steven D'Aprano schreef: >> >> And here you re-import the name "y" from struct_global. That rebinds the >> current module's "y" with whatever value struct_global.y has *now*, >> rather than a second (or a minute, or an hour) earlier when the first >> import took place. Obviously at some point between the first import and >> the second import, struct_global.y must have been reassigned from -1 to >> 62. >> >> This goes to show why global variables are considered harmful, and why >> clean, modern program design tries to reduce the use of them as much as >> possible. Global variables are too easily modified by, well, *anything*. >> The sort of behaviour you are seeing is sometimes called "action at a >> distance" -- something, anything, anywhere in your program, possibly >> buried deep, deep down inside some function you might never suspect, is >> changing the global variable. > > I think you are overstating your case. Classes and functions are > variables too and in general nobody seems to have a problem with them > being global. >
It's global *variables* that are to be avoided. constants like clsases and functions are fine. On the other hand, class attributes can be variable, and thus are to be avoided when reasonable. There *are* places where global variables make sense, such as for caching, or counting. But those are typically hidden, so they are global in lifetime, but not in scope. -- DaveA -- http://mail.python.org/mailman/listinfo/python-list