ark> It makes me uneasy because the behavior of programs might depend ark> on the order in which modules are loaded. That's why I didn't ark> suggest a way of defining the variations on f in separate places. David> This concern seems most un-pythonic to my eye, since there are David> already all kinds of ways any module can change the behavior of David> any call in another module. The moset direct way is by David> rebinding the implementation of another module's David> function. Python is a dynamic language, and that is usually David> seen as a strength. Indeed. What concerns me is not dynamic behavior, but order-dependent behavior that might be occurring behind the scenes. I would really like to be confident that if I write import x, y it has the same effect as import y, x I understand that there is no guarantee of that property now, but I suspect that most people write programs in a way that does guarantee it. I would hate to see the language evolve in ways that makes it substantially more difficult to avoid such order dependencies, so I am reluctant to propose a feature that would increase that difficulty. David> More importantly, though, forcing all the definitions to be in David> one place prevents an important (you might even say the most David> important) use case: the author of a new type should be able to David> provide a a multimethod implementation corresponding to that David> type. For example, if I write a rational number class, I should David> be able to plug in a corresponding arctan implementation. Yes. I'm not saying such a feature shouldn't exist; just that I don't know what form it should take. David> I'm extra-surprised to see that Andy's uneasy about this, since David> a C++ feature which (colloquially) bears his name was David> purpose-built to make this sort of thing possible. Koenig David> lookup raises a similar issue: that the behavior of a function David> call can be changed depending on which headers are #included, David> and even the order they're #included in. The C++ #include mechanism, based as it is on copying source text, offers almost no hope of sensible behavior without active collaboration from programmers. David> [I personally have many other concerns about how that feature David> worked out in C++ - paper available on request - but the Python David> implementation being suggested here suffers none of those David> problems because of its explicit nature] Which doesn't mean it can't suffer from other problems. In particular, if I know that modules x and y overload the same function, and I want to be sure that x's case is tested first, one would think I could ensure it by writing import x, y But in fact I can't, because someone else may have imported y already, in which case the second import is a no-op. -- Andrew Koenig, ark@research.att.com, http://www.research.att.com/info/ark