[Python-Dev] multimethods: missing parts (was: type categories)

[Samuele Pedroni]

[Greg Ewing]
>So far no-one has addressed the other importing problem
>I mentioned, which is how to ensure that the relevant
>modules get imported *at all*.

We were busy agreeing on the basic stuff  :(.

>
>Currently in Python, a module gets imported because
>some other module needs to use a name from it. If no
>other module needs to do so, the module is not needed.
>
>But with generic functions, this will no longer be
>true. It will be possible for a module to be needed
>by the system as a whole, yet no other module knows
>that it is needed!

What a dramatic personification <wink>!

Yes it's a real bookkeeping problem.

Sidenote: Common Lisp
systems deliver programs as whole
system images, and one often uses an image
to store development snapshots.
So it's not really an issue for the program
at startup. Libraries nevertheless
should come with "scripts" that assure
that all their relevant parts are loaded.
OTOH as long as a programmer immediately
loads his definitions/redefinitions and use
the image for snapshots he can forget about
the issue. But even he should still care about being
able to reload/reconstruct the system from
the source files and from scratch.
So in the end the problem is not completely
only a Python problem.

At the moment the following bookkeeping
rules come to my mind to address the issue:

- a module in a library that exposes
a generic function defined by the library
(defgeneric) should make sure that all the definitions
of methods in the library are already added to the
generic function once the generic function is exposed.

- a module in a library that exposes classes for which
it adds specialized methods
to a generic function defined in and imported
from another library, should assure that once
the class instances can be obtained the specialized
versions are already added.

It seems to me that this should cover most of
the sane cases.

Recap/
Issues' orthogonal and not so orthogonal decomposition:

- Support for multimethods can be written in (pure) Python
today, at this level the question is whether to have such
support in the std lib or not;
- if my understanding is correct Dave Abrahams wants
multimethod dispatch as the moral equivalent of static
overloading, for that use gf-method definitions would in most cases
be just in one place (especially if what we are "overloading"
is a normal class method)  and the generic function is expected to
be used just as a normal function;
- nice to have: dispatch on protocols/categories; this intersect
a  well-known everrecurrent  issue;
- how much should multimethods become part of the language?
are they a useful addition?  what about newbies? can multimethods be made play
nice
with the rest of the language (especially with single dispatch and normal class
methods [*])?
will they eventually deserve syntax sugar? are they a Py3K thing?

and-who-put-that-multimethods'-evangelist-hat-on-my-head-?-[and-I-had
not-much-time-(still-true)]-who?-and-now-I-will-hypnotize-you-all-and-everybody
-should-buy-the-AMOP-ly y'rs - Samuele.

[*] at the moment personally I see two possibilities:
- have a type of generic function that can live inside a class (namespace)
be able to redispatch (maybe just only if appropriately configurated)
to superclasses' methods if no matching gf-method is found.
 [after, before, around methods would be  difficult (impossible?) to
implement with the right semantics]
- redefine the normal dispatch rules (obj.meth(...)) in order to directly
take care of generic functions inside classes [larger change]