[Python-Dev] type categories

[David Abrahams]

From: "Greg Ewing" <greg@cosc.canterbury.ac.nz>


> David Abrahams <dave@boost-consulting.com>:
>
> > This concern seems most un-pythonic to my eye, since there are already
> > all kinds of ways any module can change the behavior of any call in
> > another module.
>
> Yes, but most of the time you don't have to use them!
> With this feature, it would be the *normal* way of using
> it.

I don't understand. You still don't have to use it. Nobody would force you
to add or encourage multimethod overloads. In fact, I think it would be
most appropriate if multimethods meant to be overloaded had to be declared
explicitly.

> > forcing all the definitions to be in one place prevents an important
> > (you might even say the most important) use case: the author of a new
> > type should be able to provide a a multimethod implementation
> > corresponding to that type.
>
> You can get that without the notion of a generic function as a
> separate entity. Just have a dispatch mechanism that looks in all the
> arguments of a call for a method to use, instead of just the first
> one.
>
> That would be relatively tractable, since at least you'd know that the
> method must be found in one of the argument classes somewhere.

Nooooo-o-o-o-o....!

(Sorry, I'm overreacting... but just a little)

That approach suffers from all the problems of Koenig lookup in C++.
Namely, if I provide a method foo in my class, and two different modules
are invoking "foo", whose idea of the "foo" semantics am I implementing?
That really becomes a problem for authors of generic functions (the ones
that call the multimethods) because every time they call a function it
essentially reserves the name of that function for the semantics they're it
to have. This is currently, IMO, one of the most-intractable problems in
C++ and I'd hate to see Python go down that path.** If you want to see the
gory details, ask me to send you my paper about it.

> It also doesn't suffer from the who-imports-the-module problem, since
> someone must have imported it in order to get an object of that class
> in the first place.

I don't think that's a serious problem. Multimethod definitions that apply
to a given type will typically be supplied by the same module as the type.

> The use case that this doesn't cover is where you're not defining a
> new class, just trying to add behaviour to handle a previously
> unanticipated combination of existing classes.  The organisational
> problems involved in that aren't unique to Python, and seem to me an
> inherent feature of the problem itself. Where does functionality
> belong that isn't owned by any class?

Often there's behavior associated with combinations of classes from the
same package or module. It's reasonable to supply that at module scope.
Besides the practical problems mentioned above, I think it's unnatural to
try to tie MULTImethod implementations to a single class. When you try to
generalize that arrangement to two arguments, you end up with something
like the __add__/__radd__ system, and generalizing it to three arguments is
next to impossible.

Where to supply multimethods that work for types defined in different
modules/packages is an open question, but it's a question that applies to
both the class-scope and module-scope approaches

-Dave

** Python is very nice about using explicit qualification to associate
semantics with implementation (i.e. we write self.foo(x) and not just
foo(x)), and this would be a major break with that tradition. Explicit is
better than implicit.