[Python-bugs-list] Exec statement inconsistency (PR#175)

guido@CNRI.Reston.VA.US guido@CNRI.Reston.VA.US
Thu, 13 Jan 2000 07:29:23 -0500 (EST)


Tim Peters wrote:
> Guido, please take another look at Vadim's original report too.  I believe I
> was too hasty in dismissing it.  exec'ing f.func_code (as he did) really
> isn't the same as calling or exec'ing f() (as I did), so if the above is a
> bug (no argument from me), I expect Vadim's original case should also be
> considered broken.  Or, if it's not, why it's not is excruciatingly subtle.

Tim, and Vadim: Even though Vadim made a good analysis and proposed a
fix, I'm not going to change this (even if the fix is correct, which I
can't judge without more testing than I have time for).  *If* I have
to make a change in response to this PR, I'm going to change it so
that the exec statement will refuse the code of a function object,
since this is the crux of the problem: while exec takes a code object,
not all code objects are considered equal.

The code object for a function is intended to take arguments and
return a value, while a code object for the exec statement is intended
to do neither.  I don't see a particular good reason why one would
*want* to execute the code object of a function independently, and I
don't want the implementation of the language to be bound by this
requirement.  I can imagine all sorts of optimizations and other
implementation techniques that would make it even harder to allow
exec'ing f.func_code correctly, so I'd rather forbid this than work
hard to allow it.

Access to a function's code object is given for a different reason: a
debugger or code analyzer can dig useful information out of it.

Hope this explains it,

--Guido van Rossum (home page: http://www.python.org/~guido/)