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
--
http://mail.python.org/mailman/listinfo/python-list
