[Python-Dev] type categories

[David Abrahams]

From: "Andrew Koenig" <ark@research.att.com>

> Greg> so you're not gaining much from the new syntax.
>
> I'm not so sure.  The code is alreasy somewhat simpler here, and it
> would be substantially simpler in examples such as
>
>         def arctan(x):
>             ...
>         else arctan(y, x):
>             ...
>
> >> It might also be possible to modify a multimethod dynamically,
> >> e.g. later one could write:
> >>
> >> def f4(a: Cat4):
> >> ...code for Cat4...
> >>
> >> f.add(f4)
>
> Greg> This sort of scheme makes me uneasy, because it means that any
module
> Greg> can change the behaviour of any call of f() in any other
> Greg> module.
>
> It makes me uneasy because the behavior of programs might depend on the
> order in which modules are loaded.  That's why I didn't suggest a way
> of defining the variations on f in separate places.

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. The moset direct way is by rebinding the implementation of another
module's function. Python is a dynamic language, and that is usually seen
as a strength.

More importantly, though, 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. For example, if I write a
rational number class, I should be able to plug in a corresponding arctan
implementation.

I'm extra-surprised to see that Andy's uneasy about this, since a C++
feature which (colloquially) bears his name was purpose-built to make this
sort of thing possible. Koenig lookup raises a similar issue: that the
behavior of a function call can be changed depending on which headers are
#included, and even the order they're #included in.

[I personally have many other concerns about how that feature worked out in
C++ - paper available on request - but the Python implementation being
suggested here suffers none of those problems because of its explicit
nature]

-Dave