[Python-3000] Generic functions vs. OO

[Guido van Rossum]

On 11/23/06, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 05:55 PM 11/23/2006 +0000, Paul Moore wrote:
> >On 11/23/06, Guido van Rossum <guido at python.org> wrote:
> > > I'm reposting this under a different subject because the other subject
> > > seems to have gone off on a tangent. The rest are Phillip's words.
> >[...]
> >
> >OK, I've read and tried to digest this. It looks good. The one thing
> >I'm still not getting, at a very concrete level, is precisely what
> >changes are required to Python to make it work.
>
> No changes as such, just additions:
>
> 1. defop, addmethod/__addmethod__, maybe hasmethod/__hasmethod__
> 2. some generic function implementation that can be applied to "normal"
> Python functions
>
>
> >  The code is clear
> >enough, but it's subtly not Python... For example, the comment "(I am
> >assuming here that normal functions are implicitly overloadable, even
> >if that means they change type at runtime to do so.)" - I don't
> >understand what, if anything this implies about the semantics of the
> >"def" statement (assuming that's the statement involved).
>
> No changes in semantics to "def".  I'm just saying that you have to be able
> to call:
>
>      addmethod(a_function, methodfunc, a_class)
>
> And have the existing simple Python function 'a_function' be overloaded as
> a result.  RuleDispatch and PEAK-Rules do this by replacing the function's
> func_code with some newly-generated dispatching code, but if this is to
> become a feature of the Python language, it might be better to simply allow
> subclassing FunctionType, and let the addmethod operation change the
> function's __class__ on the fly.  This would allow generic function
> implementations to be written in C without additional calling overhead, but
> still just modify the original object in-place instead of having to replace it.
>
> (You can't just replace the function with a *different* object, because by
> the time you overload it, there may be lots of references to it already.)
>
> It may be that if a_function doesn't have an __addmethod__, then
> addmethod() should try to call some special method (__overload__?) on
> methodfunc (in case it's been decorated with something that knows how to
> turn a_function into a generic function.  Finally, if neither side knows
> what to do, addmethod() should default to using some built-in or stdlib
> generic function implementation.

Changing the class can't add fields to the C struct that represent the
object (since that would mean realloc()'ing the object and hence
potentially changing its address). So why not make this a capability
of the base function type, rather than messing with __class__?

(This is not an endorsement of the whole thing, which I haven't read yet.)

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