[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