[Python-3000] PEP Parade

[Guido van Rossum]

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 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/)