How do I do this? (eval() on the left hand side)

[Peter Hansen]

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
globals().

Other modules just do "import const" and then things like
"const.DAQmx_Val_Volts" to get access to any of the over 1700
defined values.

In general I would say that mucking with globals() like this is
probably best restricted to constants like in this case, if at all.

-Peter