[Python-3000] PEP Parade (original) (raw)

Guido van Rossum guido at python.org
Tue May 1 21:14:47 CEST 2007

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 <pje at telecommunity.com> 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 funccode (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/)

More information about the Python-3000 mailing list