PyMyth: Global variables are evil... WRONG!

Rick Johnson rantingrickjohnson at
Tue Nov 12 18:00:37 CET 2013

On Tuesday, November 12, 2013 9:33:50 AM UTC-6, jongiddy wrote:
> I'm not sure where you get the feeling you're accessing an
> interface.

Because the constant PI should never change. Sure we can
argue about granularity of PI, but that argument has no
weight on the fact that PI should be a constant.

By placing PI in the module "math", we are creating a pseudo
interface. We (the creators) are "assuming" that PI will be a
constant and never change, and the caller is assuming that
pi will remain static,  but not only can it be mutated, it
can be mutated globally.

math.pi is neither a constant nor a local module attribute,
math.pi is really a global variable. This is true not only
for math.pi, but ALL attributes of ALL python modules.

> If I typed this, I would feel like I was trying
> to change a fundamental constant. You have just
> demonstrated that going into other modules and changing
> their attributes (whether they are variables, functions or
> classes) is generally a BAD idea, and I don't think I've
> ever seen anyone recommend doing this, except possibly as
> a workaround or for debugging purposes. On the other hand,
> you initially suggested that modifying globals contained
> within namespaces (i.e. modules) is a good way to
> communicate between modules.

You missed my point: only IF python modules were TRUE
interfaces. It's not a good idea under python's current
implementation of modules. My thread is intended to
underscore this very design flaw.

> This inconsistency

There is no inconsistency in my logic, quite the contrary.

I think you're having difficulty following along because
you've been brainwashed by Python for too long. You've
falsely believed that Python does not have globals, but
it does! You just have to mutate then via a pseudo

> is why I was asking for a good example (i.e.
> a realistic example where the use of global variables
> provides the best solution).

I gave a good example in my very first post:

    RR: "Globals are justified when they are used to
    [share] information between scopes that otherwise
    were meant to be mutually exclusive. One good
    example would be package sub-modules."

> Just because a tool allows you to do something does not
> make it a good idea. Try this paraphrase of your last
> post: Ladder designers act like standing on the top rung
> is SO evil, but then they give us ladders with a top rung,
> Are they just trying to fool themselves, or fool us?

EXACTLY. And whilst your comparison is both intelligent and
funny, you're just re-iterating my point!

We have all been brainwashed by authorities. First they
give us rules, then they give us the power to break
those rules. If standing on the top rung is SO
dangerous, then don't manufacture your ladders with top
rungs. Else, shut up about it!


Well i can't live WITH the B!@$%!!!


Then why create me with a unquenchable desire for sex?


GOD DAMMIT! Stop making all these opposing rules.

So the designers detest globals huh? But python module
attributes are really global because they can be accessed
and mutated ANYWHERE!". This enigma leads to two logical
design philosophies: (anything else is folly)

   1. Accept that globals are useful, and make them
      available through a "real" global syntax, not
      some attribute of a module that "appears" to be
      local, but in reality is global. Then prevent
      external mutation of module attributes directly,
      and instead, require that mutation must follow a
      contract defined by internal module "setter"

   2. Remain convinced that global mutation is evil
      and prevent mutation of all python module
      attributes. You can import modules, but you can't
      mutate their contents.


@LanguageDesigners: But whatever you do, don't hide globals
behind pseudo interfaces, because then you have created
something worse than a global; you've created a global in
sheep's clothing. And you're a hypocrite.

More information about the Python-list mailing list