Argh, someone *could* pass around a copy of locals() and make an assignment into that.
Not when the locals() is that of a CPython function, and I expect the same is true of Jython functions.
Well, the effect is undefined; there may be things you can do that would force the changes out to the real local variables.
But I think we're already deprecating non-read-only use of locals(), so I'd like to ban that as abuse.
FWIW, both Zope 3 and PEAK currently make use of 'locals()' (actually, sys._getframe()) to modify locals of a class or module scope (i.e. non-functions). For both class and module scopes, it seems to be implied by the language definition that the local namespace is the __dict__ of the corresponding object.
So, is this deprecated usage for class and module objects too?
It isn't. I'm not sure it shouldn't be; at some point it might be attractive to lock down the namespace of certain modules and classes, and in fact new-style classes already attempt to lock down their __dict__. Fortunately the __dict__ you see when executing a function during the class definition phase is not the class dict; the class dict is a copy of it taken by the class creation code. --Guido van Rossum (home page: http://www.python.org/~guido/)