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

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 mailing list