How To Use A Dictionary Loaded From One Module Into The Main Program From Another Module Loaded After That?

If I use a function to read the contents of a file in one module: def get_objectstore(): with open(os.getcwd() + '\\data.store', 'rb') as infile: objA = cPickle.load(i

Solution 1:

How can I use objectstore in all other modules loaded into the main program.

This is one of those things that you can do, but almost certainly shouldn't… so first I'll explain how, then explain why not.

---

If you want something to be directly available in every module, without having to import it in each module, just as if it were a builtin… the answer is to add it to the builtins. So, how do you do that?

Well, technically, there's no guaranteed safe way to do it, but practically, I believe monkeypatching the builtins module works in every version of every major implementation. So:

import builtins
builtins.objectstore = objectstore

Note that in Python 2.x, the module is called __builtin__, but works the same way.

---

This doesn't work in a few cases, e.g., inside code being run by an exec with a custom globals that provides a custom __builtins__. If you need to handle that… well, you can't handle it portably. But what if you only care about CPython (and I think PyPy, but not Jython, and I don't know about Iron…)? In CPython, it's guaranteed that every global environment, even the ones created for compile, exec, etc., will contain something named __builtins__ that's either the builtin dict for that environment, or some object whose namespace is the builtin dict for the environment. If there are no builtins at all, or you're looking at the global environment for the builtins module itself, it may be missing. So, you can write this:

try:
    __builtins__['objectstore'] = objectstore
except AttributeError:
    __builtins__.objectstore = objectstore

(That doesn't handle the case where you're running code inside the builtins namespace itself, because… I'm not sure what you'd want to do there, to be honest.)

Of course that's ugly. That's probably on purpose.

---

Now, why don't you want to do that?

Well, for one thing, it makes your code a lot harder to read. Anyone looking at your code can't tell where objectstore was defined, except by searching some completely unrelated module that isn't even referenced in the current module.

For another, it can lead to problems that are hard to debug. If you later change the list of which modules import which other modules, some module that depends on objectstore being patched in may run before it's been patched in and therefore fail.

Also, the fact that it's not actually documented that you can monkeypatch builtins, or that doing so affects the builtin environment, is a good sign that it's not something you should be relying on.

It's better to make what you're doing explicit. Have objectstore be a module global for some module that every other module imports from. Then it's immediately clear what's happening, on even a cursory glance.

For example, why not add that objectstore = get_objectstore() to mainvars, and then have every module do from mainvars import objectstore? Or maybe you even want to make it a singleton, so it's safe for anyone to call get_objectstore() and know that they'll all get back a single, shared value. Without knowing exactly what you're trying to accomplish, it's hard to suggest a best solution. All I can say for sure is that making objectstore a builtin-like cross-module global is very unlikely to be the best solution for almost anything you might be trying to accomplish.