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

Guido van Rossum guido at python.org
Wed May 2 02:52:16 CEST 2007

On 5/1/07, Phillip J. Eby <pje at telecommunity.com> wrote:

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.

I admit I'm new to this game -- but most 3.0 users will be too. But I would be rather fearful of someone else stomping on a function I defined (and which I may be calling myself!) without my knowing it. ISTM (again admittedly from the fairly inexperienced perspective) that most functions and methods just aren't going to be useful as generic functions. The most likely initial use cases are situations where people sit down and specifically design an extensible framework with some seedling GFs and instructions for extending 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.

Looking at it from a different way, you do have to mark APIs to be subclasses explicitly -- using the "class" syntax. You can leave that out, and then you end up with a bunch of functions in a module. Every time I write some code I make a conscious decision whether to do it as a class or as a method -- I don't create classes for everything by default.

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!

So this example can be interpreted both way -- sometimes you have to declare an anticipated use, sometimes you don't. It still hasn't convinced me that it's such a burden to have to declare GFs. I rather like the idea that it warns readers who are new to GFs and more familiar with how functions behave in Python 2. I can guarantee that very few people are aware of being able to assign to func_code (hey, I had to look it up! :-).

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 funccode 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.

I see your PBP and I raise you an EIBTI. :-)

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.

No plans in that direction. Just general discomfort with depending on the feature. Also noting that code is an implementation detail -- it doesn't exist for other callables such as built-in functions.

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-3000 mailing list