At 11:31 AM 5/1/2007 -0700, Guido van Rossum wrote: >I haven't had the time to read this in detail, but in general I'm >feeling favorable about this idea. I'd rather see it decoupled from >sys._getframe() and modifying func_code (actually __code__ nowadays, >see PEP 3100).
I've figured out how to drop *some* (but not all) of the _getframe() hackery from the current proposal, btw. (Specifically, I believe I can make the decorators decide which function to return using __name__ comparisons instead of by checking frame contents.) Regarding __code__, however, it's either that or allow functions to be subclassed and have their type changed at runtime. In other words, if you could meaningfully assign to a function's __class__, then mucking with its __code__ would be unnecessary; we'd just override __call__ in a subclass, and change the __class__ when overloading an existing function. Unfortunately, I believe that CPython 2.3 and up don't let you change the type of instances of built-in classes, and it's never been possible to subclass the function type, AFAIK. OTOH, these restrictions may not exist in Jython, IronPython, or PyPy; if they allow you to subclass the function type and change a function's __class__, then that approach becomes a reasonable implementation choice on those platforms. Thus, assignment to __code__ might reasonably be considered a workaround for the limitations of CPython in this respect, rather than a CPython-dependent hack. :) _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
