From: "Andrew Koenig"
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