Re: getting at the current frame
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/)
"GvR" == Guido van Rossum <guido@python.org> writes:
GvR> The other, perhaps more major, problem with this it is that GvR> you can't easily wrap functions that use it in other GvR> functions. Normally, if there's a function foo(arg) that GvR> does something, I can write a function wrapfoo(arg) that does GvR> something else, then calls foo(arg), and then does another GvR> thing. But if foo() uses getframe(), that's not so easy: the GvR> call to foo() in wrapfoo() will access wrapfoo()'s frame. GvR> A way around this would be to implement foo as a call to GvR> (e.g.) _foo(arg, frame), and define foo(arg) as _foo(arg, GvR> sys.getframe()). Then _wrapfoo(arg, frame) could be defined GvR> as a wrapper around _foo(arg, frame) and wrapfoo(arg) as GvR> _wrapfoo(arg, sys.getframe()). Darn good point. So where could we put it? It's a useful introspection device. If it goes in a separate module, should that perhaps be called `reflection'? Or maybe `runtime'? Or maybe "sys._getframe()" is good enough. -Barry
barry@wooz.org discourseth:
Hmm..I'd think `reification' instead of `reflection'. My understanding was that reification involves taking an implicit language entity and making it an expressed value (e.g., getframe() or call_with_current_continuation()) while reflection goes in the opposite direction (e.g., eval()). pedantically, e
sys._getframe() is good enough. --Guido van Rossum (home page: http://www.python.org/~guido/)
"BAW" == Barry A Warsaw <barry@wooz.org> writes:
"GvR" == Guido van Rossum <guido@python.org> writes:
GvR> sys._getframe() is good enough. BAW> Cool, I'll upload the patch to SF. Patch #102106 http://sourceforge.net/patch/?func=detailpatch&patch_id=102106&group_id=5470 (includes doc patch) -Barry
"GvR" == Guido van Rossum <guido@python.org> writes:
GvR> The other, perhaps more major, problem with this it is that GvR> you can't easily wrap functions that use it in other GvR> functions. Normally, if there's a function foo(arg) that GvR> does something, I can write a function wrapfoo(arg) that does GvR> something else, then calls foo(arg), and then does another GvR> thing. But if foo() uses getframe(), that's not so easy: the GvR> call to foo() in wrapfoo() will access wrapfoo()'s frame. GvR> A way around this would be to implement foo as a call to GvR> (e.g.) _foo(arg, frame), and define foo(arg) as _foo(arg, GvR> sys.getframe()). Then _wrapfoo(arg, frame) could be defined GvR> as a wrapper around _foo(arg, frame) and wrapfoo(arg) as GvR> _wrapfoo(arg, sys.getframe()). Darn good point. So where could we put it? It's a useful introspection device. If it goes in a separate module, should that perhaps be called `reflection'? Or maybe `runtime'? Or maybe "sys._getframe()" is good enough. -Barry
barry@wooz.org discourseth:
Hmm..I'd think `reification' instead of `reflection'. My understanding was that reification involves taking an implicit language entity and making it an expressed value (e.g., getframe() or call_with_current_continuation()) while reflection goes in the opposite direction (e.g., eval()). pedantically, e
sys._getframe() is good enough. --Guido van Rossum (home page: http://www.python.org/~guido/)
"BAW" == Barry A Warsaw <barry@wooz.org> writes:
"GvR" == Guido van Rossum <guido@python.org> writes:
GvR> sys._getframe() is good enough. BAW> Cool, I'll upload the patch to SF. Patch #102106 http://sourceforge.net/patch/?func=detailpatch&patch_id=102106&group_id=5470 (includes doc patch) -Barry
participants (3)
-
barry＠wooz.org -
est＠hyperreal.org -
Guido van Rossum