[Python-Dev] Re: getting at the current frame

[Guido van Rossum]

>     GvR> Agreed.  I think it's good to have the functionality
>     GvR> available, but it's also good to make it *real* clear not to
>     GvR> mess with it unless you really know what you're doing.  Maybe
>     GvR> it should be in a separate module or at least have a leading
>     GvR> _underscore.
> 
> I think you're fairly safe from mischief since the only writable
> attributes of a frame object are f_trace, f_exc_type, f_exc_value, and
> f_exc_traceback.  The same caveats about f_globals and f_locals apply
> as with the dicts returned by locals() and globals().

It's not so much that it's easy to do damage with.  I have a
philosophical problem with making this a feature that people can use
whenever they feel like.  It's a messy feature and its use should
limited as an implementation aid for language features like variable
substitution.

The other, perhaps more major, problem with this it is that you can't
easily wrap functions that use it in other functions.  Normally, if
there's a function foo(arg) that does something, I can write a
function wrapfoo(arg) that does something else, then calls foo(arg),
and then does another thing.  But if foo() uses getframe(), that's not
so easy: the call to foo() in wrapfoo() will access wrapfoo()'s frame.

A way around this would be to implement foo as a call to (e.g.)
_foo(arg, frame), and define foo(arg) as _foo(arg, sys.getframe()).
Then _wrapfoo(arg, frame) could be defined as a wrapper around
_foo(arg, frame) and wrapfoo(arg) as _wrapfoo(arg, sys.getframe()).

This is another reason to be very selective in the use of getframe().

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