Question

Stack Overflow has a lot of questions regarding global variables in python, and it seems to generate some amount of confusion for people coming from other languages. Scoping rules don’t exactly work the way a lot of people from other backgrounds expect them to.

At the same time, code is meant to be organized not so much on class level, but on module level. So when everything is not necessarily contained in classes, state that would otherwise be found in member variables can go in module-level variables.

So my question is 2 part:

1) Should I be avoiding the use of globals (specifically setting them from within functions and using the global keyword)?

2) If #1 is yes, are there common patterns where they are expected to be used?

I work in a place where lots of different languages abound and I want to mitigate confusion and make sure that pythonistas won’t hate me later.

Thank you for any constructive input.

Answer 1

I highly recommend you read this blog post titled Singletons and their Problems in Python. It has caused me to rethink my use of global variables. Some choice quotes:

But beware. Just because you do not implement the singleton design pattern it does not mean you avoid the core problem of a singleton. The core problem of a singleton is the global, shared state. A singleton is nothing more than a glorified global variable and in languages like Java there are many reasons why you would want to use something like a singleton. In Python we have something different for singletons, and it has a very innocent name that hides the gory details: module.

That’s right folks: a Python module is a singleton. And it shares the same problems of the singleton pattern just that it’s a little bit worse.

And here is one example of problems having such shared state might cause:

In order to not talk about irrelevant things, let’s have a look at one of the modules from the standard library, the mimetypes module.

Have a look:

inited = False

def init(files=None):
    global inited
    db = MimeTypes()
    ...

This is actual code from the mimetypes module that ships with Python, just with the more gory details removed. The point is, there is shared state. And the shared state is a boolean flag that is True if the module was initialized or False if it was not. Now that particular case is probably not that problematic (trust me, it is) because mimetypes initializes itself, but you can see that there is a files parameter to the init function. If you pass a list of files to that function, it will reinitialize the mime database in memory with the mime information from those files. Now imagine what would happen if you have two libraries initializing mimetypes with two different sources …

That’s a common enough pattern, and I’ve done it myself… but for example a better way to do it would be: init returns an instance of a class that implements all the methods, and other parts of the code can init to get a different instance with different parameters that don’t interfere with the former. The "downside" is that you have to pass this instance to any code that doesn’t want to initialize a new one, but the upside of that "downside" is that it makes it obvious what your dependencies are.

Anyway, in short, I’d try to avoid it as much as possible, but if you’re ok with code having an implicit singleton then go for it.