On Wed, 13 Nov 2013 23:42:24 +0000, Rhodri James wrote: > On Tue, 12 Nov 2013 02:06:09 -0000, Rick Johnson > <rantingrickjohn...@gmail.com> wrote: > >> PyMyth: Global variables are evil... WRONG! > > That's not a PyMyth. It's a CompSciMyth, or to be more accurate a good > general Software Engineering guideline regardless of language.
To be precise, it's not a myth at all. Just because there are occasional medical uses for digitalis doesn't make it a myth that it is deadly poison. Just because there are occasional programming uses for global variables doesn't make it a myth that they are poor practice and lead to hard-to-maintain, unsafe, buggy code. > Like all > guidelines it can be broken, but people who break it should do so > knowingly, aware that they have created potential problems for > themselves. Absolutely correct. >> ============================================================ >> The denial of the 99%: >> ============================================================ Python has >> globals, but we just can't admit it! > > A different subject entirely, but no more accurately stated. Completely inaccurately stated. It certainly isn't true that "99%" of people (who exactly? Rick doesn't say) claim that Python has no globals. That would be a stupid thing to say for a language with a "global" keyword, a "globals" function, and a built-in module that is shared across the entire process. > [snip] >> But even the "module level" globals can be accessed "globally" if the >> module they are contained in is imported everywhere. > > Remember when I said that guidelines can be broken? I think you know the following, but for anyone else reading... Just because a module global alpha.spam is accessible to anything that imports the module doesn't make it a process-wide global. The ability to do this: import alpha alpha.spam = 23 does not make "spam" a process-wide global. It just means that attribute access on the module object is the supported interface for manipulating names in namespaces which are modules. There is very little practical difference apart from convenience between directly manipulating attributes as above, and using a setter function like "setattr(alpha, 'spam', 23)". Python tries to avoid boilerplate. Since manipulating attributes is useful, a philosophy of consenting adults applies and we have direct access to those attributes, with an understanding that we should use this power with care. With great power comes great responsibility -- if you're going to reach inside another module and manipulate things, you ought to know what you're doing. One of the numerous problems with process-wide globals is that there's no encapsulation and consequently one package's use of "spam" clobbers another package's use of "spam" for a different purpose. But that's not the case here: alpha's "spam" is separate from module omega's "spam" variable. To give an analogy: just because I can walk through the door of number 23 Alpha Street and rummage through their fridge, and walk through the door of number 42 Omega Road and do the same, doesn't mean that the two fridges are actually the same fridge. -- Steven -- https://mail.python.org/mailman/listinfo/python-list