> 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4