[Python-Dev] issue5578 - explanation
jeremy at alum.mit.edu
Wed Apr 1 18:21:03 CEST 2009
Eeek, I think it was me. Part of the AST changes involved raising a
SyntaxError when exec was used in a scope that had a free variable,
since the behavior is pretty much undefined. If the compiler decides
a variable is free, then it can't be assigned to in the function body.
The compiled exec code can't know whether the variable is local or
free in the exec context, only that it should generate a STORE_NAME
opcode. The STORE_NAME can't possibly work.
It looks like I did a bad job of documenting the change, though. I
had forgotton about it ,because it was three or four years ago.
It looks like the same exception should be raised for the class statement.
On Wed, Apr 1, 2009 at 11:00 AM, R. David Murray <rdmurray at bitdance.com> wrote:
> On Wed, 1 Apr 2009 at 13:12, Chris Withers wrote:
>> Guido van Rossum wrote:
>>> Well hold on for a minute, I remember we used to have an exec
>>> statement in a class body in the standard library, to define some file
>>> methods in socket.py IIRC.
>> But why an exec?! Surely there must be some other way to do this than an
> Maybe, but this sure is gnarly code:
> _s = ("def %s(self, *args): return self._sock.%s(*args)\n\n"
> "%s.__doc__ = _realsocket.%s.__doc__\n")
> for _m in _socketmethods:
> exec _s % (_m, _m, _m, _m)
> del _m, _s
> Guido's memory is good, that's from the _socketobject class in
> Python-Dev mailing list
> Python-Dev at python.org
More information about the Python-Dev