[Python-3000] PEP Parade
Phillip J. Eby
pje at telecommunity.com
Tue May 1 21:07:36 CEST 2007
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. :)
More information about the Python-3000
mailing list