[Python-3000] PEP Parade

[Phillip J. Eby]

At 02:04 PM 5/1/2007 -0700, Guido van Rossum wrote:
>On 5/1/07, Phillip J. Eby <pje at telecommunity.com> wrote:
> > At 12:14 PM 5/1/2007 -0700, Guido van Rossum wrote:
> > >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?
> >
> > The ability to overload any function, without having to track down all the
> > places it's already been imported or otherwise saved, and change them to
> > point to a new function or a non-function object.
>
>Frankly, I'm not sure this is worth all the proposed contortions. I'd
>be happy (especially as long as this is a pure-Python thing) to have
>to flag the base implementation explicitly with a decorator to make it
>overloadable. That seems KISS to me.

I can see that perspective; in fact my earlier libraries didn't have this 
feature.  But later I realized that making only specially-marked functions 
amenable to overloading was rather like having classes that had to be 
specially marked in order to enable others to subclass them.

It would mean that either you would obsessively mark every class in order 
to make sure that you or others would be able to extend it later, or you 
would have to sit and think on whether a given class would be meaningful 
for other users to subclass, since they wouldn't be able to change the 
status of a class without changing your source code.  Either way, after 
using classes for a bit, it would make you wonder why classes shouldn't 
just be subclassable by default, to save all the effort and/or worry.

Of course, I also understand that you aren't likely to consider overloads 
to be so ubiquitous as subclassing; however, in languages where merely 
static overloading exists, it tends to be used just that ubiquitously.  And 
even C++, which requires you to declare subclass-overrideable methods 
as  "virtual", does not require you to specifically declare which names 
will have overloads!

But all that having been said, it appears that all of the current major 
Python implementations (CPython, Jython, IronPython, and PyPy) do in fact 
support assigning to func_code as long as the assigned value comes from 
another valid function object.  So at the moment it certainly seems 
practical (if perhaps not pure!) to make use of this.

Unless, of course, your intention is to make functions immutable in 
3.x.  But that would seem to put a damper on e.g. your recent "xreload" 
module, which makes use of __code__ assignment for exactly the purpose of 
redefining a function in-place.