How do I do this? (eval() on the left hand side)
peter at engcorp.com
Thu Dec 9 20:04:55 CET 2004
Jeff Shannon wrote:
> Of course, just because modifications of the dict returned by globals()
> *do* reliably result in modifications to the global namespace, doesn't
> mean it's a good idea. ;)
"The" global namespace misses the possibility that doing this in
"a" global namespace might be a good idea. For example, in the
namespace of a special module intended to be used as a convenient
way of accessing global information. See below.
> Personally, I don't *want* to create variables by "magic" like that.
> I'd rather pass a few extra parameters around, and explicitly create any
> global names I need. If I really need to store objects under arbitrary
> names, then I probably should be using a regular dict (and passing it
> around as need be) instead of dumping stuff into globals().
The main way I use this is in some sort of a "const" module, which
provides access to a large set of constant information. In other
words, in contrast to what you had in mind when you wrote the
above, I'm dealing with neither "variables" nor information that
_would_ best be put in a dict.
The last time I did this I had a .h header file from C which I
wanted to wrap up for Python. Rather than convert once, statically,
I had a const.py module which loaded the .h file contents and
converted all lines which it recognized (mostly lines of the
form "#define XXX nnn") into Python names stuck into that module's
Other modules just do "import const" and then things like
"const.DAQmx_Val_Volts" to get access to any of the over 1700
In general I would say that mucking with globals() like this is
probably best restricted to constants like in this case, if at all.
More information about the Python-list