...

...

...

...

"SP" == Samuele Pedroni <pedroni@inf.ethz.ch> writes:

SP> I should reformulate: I think a possible not arbitrary rule for SP> exec is only exec ... in ... is valid, but this also something SP> ok only on the long-run (like import * deprecation). Yes. SP> Then it is necessary to agree on the semantic of locals(). That's easy. Make the warning in the current documentation a feature: locals() returns a dictionary representing the local symbol table. The effects of modifications to this dictionary is undefined. SP> What would happen right now mixing lexical scoping and exec SP> ... in locals()? Right now, the exec would get flagged as an error. If it were allowed to execute, the exec would operator on the frame's f_locals dict. The locals() builtin calls the following function. PyObject * PyEval_GetLocals(void) { PyFrameObject *current_frame = PyThreadState_Get()->frame; if (current_frame == NULL) return NULL; PyFrame_FastToLocals(current_frame); return current_frame->f_locals; } This copies all variables from the fast slots into the f_locals dictionary. When the exec statement is executed, it does the reverse copying from the locals dict back into the fast slots. The FastToLocals and LocalsToFast functions don't know anything about the closure, so those variables simply wouldn't affected. Assignments in the exec would be ignored by nested scopes. Jeremy