"lynx" <noone at nowhere.net> wrote in message news:3b3e655b$0$88181$2c3e98f8 at news.voyager.net... ... > > You'd need to use the 'exec' statement (shudder), but fortunately you > > can easily do better than that, since...: > > hmm. is there something inherently evil about exec that i should know > about...? In a sense, it's "too powerful" -- it can do so many things that it's bound to have unpleasant fallback in some way or other. Clarity and ease of understanding your program is likely to be the main casualty, but there may be others. For example: usually, the compiler is able to perform a simple but crucial optimization for local variables of your functions -- it knows what variables are local (all that are bound in local scope), and it needs not insert lookup operations for local variable access into the bytecode it generates. But if the function contains an exec, all bets are off -- the compiler DOES need to insert explicit lookups, so all of the function is slowed down. So, use exec when you must, but be aware that you RARELY 'must', and there are usually better alternatives. If and when you do use exec, it's generally best to use explicit dictionaries as namespaces, to avoid accidents and slow-downs. > > Global variables are really attributes of an object, the module object > > to be precise. Setting any object's attributes is most easily done via > > built-in function setattr(). > > > So you need a reference to the object that's the module you want to > > affect. Assuming this is the module containing the function you're > > writing, simplest may be: > > import sys > > mymod = sys.modules[__name__] > > and now mymod is the reference you require. > > looks interesting. should that snippet be run in the function where i'm > trying to change these globals, or in the main program and that reference > passed in as an argument to the function? Either will work. Having it in your function will make it simpler to use. Having it on the outside makes your function more general, since it can be called with different module-object arguments to set global variables in different modules (or attributes of other objects yet). A person with any knack for overgeneralization would have mymod as an optional argument with a default value of None and do the above only if mymod is None...:-). > honestly, myself, i'd be more upset and shuddering at this kind of > manual rooting around in Python's own internal workings than at the > exec() statement, which seems designed to hide this sort of magic from > me; unless, of course, there's something strange about exec that i don't > know of...? Python is an unusual high-level language in that it DOES expose and document a wide part of how it internally goes about things, and quite explicitly empowers you to "root around" that part. It does mean one must employ good taste and common sense to avoid making one's code a mess of hard-to-understand, hard-to-maintain black magic, yes. But "exec" is still overkill for most things you can do by other means. Specifically, when you think you need exec or eval to bind or access variables whose names you don't know in advance, setattr and getattr are very likely to be a better choice. Whether they must go to a module object is another issue; often you're better served by keeping such variables as attributes of _your own_ object that you fully control, and that will most often be an instance object rather than a module object, because instance objects can check their own attributes via special methods __getattr__ and __setattr__ -- and you may not even need that much. Suppose you keep all of your configuration variables this way: class Config: one = 1 another = 23 andalso = 'feefie' config=Config() Now you can elsewhere in your code check and use config.one, config.another, config.andalso -- as the attributes are not specifically bound in the instance, you'll get the class ones. You can also allow user-configuration code to set ANY attribute of config, no checks needed -- if the user sets an attribute you're not using, that's gonna be a no-op. So you can for example: execfile("userconf.py", vars(config)) and then use config.one, etc, and get either the instance variable if user code has set it, or else the fallback class value. Alex