What should I name my global module in Python?

Question

I'm writing an application in Python, and I've got a number of universal variables (such as the reference to the main window, the user settings, and the list of active items in the UI) which have to be accessible from all parts of the program¹. I only just realized I've named the module globals.py and I'm importing the object which contains those variables with a from globals import globals statement at the top of my files.

Obviously, this works, but I'm a little leery about naming my global object the same as the Python builtin. Unfortunately, I can't think of a much better naming convention for it. global and all are also Python builtins, universal seems imprecise, state isn't really the right idea. I'm leaning towards static or env, although both have a specific meaning in computer terms which suggests a different concept.

So, what (in Python) would you call the module which contains variables global to all your other modules?

¹ I realize I could pass these (or the single object containing them) as a variable into every other function I call. This ends up being infeasible, not just because it makes the startup code and function signatures really ugly.

Answer 1

global is a keyword, not a built-in. 'globals' is not a keyword, but is a built-in function. It can be assigned to, but is bad practice. Code checkers like pylint and pychecker can catch these accidental assignments. How about config?

Answer 2

top? top_level?

Answer 3

I would try to avoid such a global container module altogether, and instead put these variables into their own modules, which can then be imported from all parts of the system.

For example, the main window would probably go into a variable in main.py. User settings could go into usersettings.py which would provide functions to view and change the settings.

If another part of the system needs to access the user settings, that's a simple matter of:

from usersettings import get_setting, set_setting
...
# Do stuff with settings

A similar approach could probably be used for other stuff that needs to be globally accessible. This leads to clearer separation of concerns and more testable code, since you can test modules in isolation without depending on the globals module all the time.

Answer 4

`config` or `settings`

Answer 5

I'd call it env. There's little risk that someone will confuse it with os.environ (especially if you organize your code so that you can call it myapp.environ).

I'd also make everything exposed by myapp.environ a property of a class, so that I can put breakpoints in the setter when the day comes that I need to.

Answer 6

from globals import Globals

This will fix the conflict and also follows PEP 8 recommendations.

Also, in other cases like this, Roget's Thesaurus is your friend. I always keep a copy nearby.