[Python-3000] Kill "generic functions"!

[Phillip J. Eby]

At 08:51 AM 4/6/2006, Aahz <aahz at pythoncraft.com> wrote:
>I cringe every time I see the phrase "generic function".  It's way too
>generic -- it doesn't contain any hint of its meaning,

And worse - "generic" in US English often implies:

* commodity
* ordinary
* cheap knock-off
* low-quality

etc.  Not the sort of ideas to associate with Python.  :)


>and I find it
>confusing because Python already has what I think of as generic
>functions:
>
>def adder(a, b):
>     return a+b
>
>That's a perfectly good generic function that depends on Python's
>duck-typing.  "Multimethods" works, but Python is in many ways
>function-oriented rather than method-oriented.  Why not call them
>"multifunctions"?

As long as we're inventing our own terminology, I vote for 
"extensible functions", as this emphasizes the benefit rather than 
the technology.  Without extensibility, there's nothing really 
special about them.  We wouldn't even be talking about them if you 
had to define all of their "methods" in one place.

We also need a term for their methods, as this gets confusing when 
talking about a gener^H^H^H^H^Hextensible function that's being used 
as an object method. I don't have as unequivocal a suggestion for 
that, but lean towards "extensions".  So, you would "extend" an 
extensible function by adding an extension:

     @extensible
     def some_function(...):
           """blah"""

     @some_function.extend(...)
     def other_thing(...):
          """bah"""

Although, depending on how extensibility is implemented, I'd suggest 
that in Py3K there should be no need for @extensible; functions could 
simply be extensible by nature, in which case, this would be sufficient:

     def some_function(...):
           """blah"""

     @extends(some_function, ...)
     def other_thing(...):
          """bah"""

Note that @extends() itself could be a function that is extensible, 
which could open the door to alternative means of doing the 
extending, so that people could have add-on libraries providing more 
advanced forms of extension that what the language itself might 
provide.  (e.g. RuleDispatch's level of customizability)

I understand that Ruby 2 is probably going to add before/after/around 
decorators that basically provide a form of @extends that allows you 
to monkeypatch an existing method.  If that's all that was built in 
to Python 3000 (i.e., a way to monkeypatch a function without messing 
with func_code), then all the more sophisticated forms of generic 
functions could be implemented on top of that.  And for really simple 
situations, like where you want to just add *one* more extension to 
an almost perfect function, that monkeypatching ability alone would 
work great, especially if it could be done in such a way that 
invoking the previous definition of the function didn't create 
function call overhead.  As soon as you add a few levels of function 
call, RuleDispatch's dispatch tree starts looking speedy by comparison.

Anyway, syntactically, that would probably look like:

     @extends(some_function)
     def some_extension(...):
         if some_condition:
             ...
         else:
             next_method(...)

And then other people could make fancier versions of @extends that 
put the conditional information into the decorator arguments instead 
of the function body.