[Python-3000] PEP Parade
Phillip J. Eby
pje at telecommunity.com
Wed May 2 02:30:20 CEST 2007
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.
More information about the Python-3000