Suppose you couldn't assign to __class__ of a function (that's too messy to deal with in CPython) and you couldn't assign to its __code__ either. What proposed functionality would you lose? How would you ideally implement that functionality if you had the ability to modify CPython in other ways? (I'm guessing you'd want to add some functionality to function objects; what would that functionality have to do?)
--Guido On 5/1/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > 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. :) > > -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
