On Sat, May 23, 2015, at 21:53, Dr. John Q. Hacker wrote: > What should happen when there's a name collision on method names between > mix-ins? Since they're mix-ins, it's not presumed that there is any > parent > class to decide. The proper thing would seem to call each method in the > order that they are written within the parent class definition.
The way C#/.NET does its nearest equivalent to this is to have this be determined by what "mix-in" is in scope at the call site. That is, for example, the mix-ins for IEnumerable defined in System.Linq.Enumerable is only called if the System.Linq namespace has been imported. IIRC, it's an error for there to be two with identical signatures, which isn't an issue since you can simply explicitly call the method as Enumerable.Whatever(foo) instead of foo.Whatever(). One could imagine a similar mechanism for python... object.__getattr__ could, if nothing is found in the dictionary or by an overridden __getattr__ method, find the call site (construct a stack trace), iterate through an __mixins__ list in the calling module, search each mixin, in order (since it's a list, let's take advantage of it having an order since we haven't got the static type system to do a lot of sophisticated overload resolution), for a matching name. Ideally we'd also have a mechanism for mixin methods to be able to raise NotImplemented (or TypeError?) and have it continue down the list, but any mechanism I can think of for this has the disadvantage that if any of the mixins contains a matching callable it has to return a proxy rather than immediately raising an error, even if none of them actually works. -- https://mail.python.org/mailman/listinfo/python-list
