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.

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.

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.

Another major limitation of using modules as instances of a singleton is that, unlike a class with an __init__() method which will be called and possibly passed arguments, it's difficult to affect / control the construction of the (single) instance created on its initial import.
–
martineauSep 28 '12 at 17:39

@Claudiu thanks, this answer gave me more than I expected :).
–
MrFoxSep 28 '12 at 19:15

In short, yes, you should be avoiding using the global keyword. It might be in the language for a reason but I generally consider it to be a code smell -- if you have some state you want to keep up, encapsulate it in a class. That's far less fragile than using global.

I take it as a hard and fast rule to never use global. Keeping all your state in a class instance is easy enough, and if you ever need to create more than one instance of a class, you should thank your lucky stars that you don't have them stepping on each other. If the state really needs to be common, then move it up a level in the class hierarchy.
–
DaveSep 28 '12 at 16:29

I sometimes tend to do foo = [globalvar] and then get and set foo[0] within functions so i don't have to use that global keyword. it sort of makes it more obvious that i'm using a global varibale cause i have to treat it 'specially', but it's still pretty ugly, much like using global variables is
–
ClaudiuSep 28 '12 at 16:30

Globals are not really taboo, it's just you have to remember to declare them as global in your function before you use them. In my opinion this actually makes them more clear because the user sees that you are explicitly using a global.

I would be more afraid of the non-pythonistas not understanding python globals, modifying your code and not adding the proper global declarations.