On Mon, Nov 28, 2016 at 10:22 AM, Guido van Rossum <guido@python.org> wrote:
At calling time, the subclass' method will be found, and used, and the
search stops there -- no way to know if there is one with the same name further up the MRO.
This is simply incompatable with a language this dynamic.
Not so fast! Python is also so dynamic that you can easily create a metaclass (or a class decorator) that does the checking (assuming reasonable behavior of all classes involved) at class definition time.
but that's class definition time -- can't classes be dynamically mangled later on -- after subclasses have been defined? If I have this right the mro is set at class definition time, so it is knows which classes are in the tree -- but class objects themselves are mutable -- methods can be added later on. so a subclass could have a method that isn't overriding anything when it's defined, but ends up overriding something later on, 'cause the base class changed under it. Isn't this why the mro is searched at method calling time? rather than a static table being used? (if not -- wouldnt that be a nice optimization?) Granted -- this kind of late class mangling has got to be pretty unusual (and maybe only useful for mocking, or??) but it is there. Which is why it could be useful to have some syntax or convention for specifying "I'm intending to override a method", that linters or type checkers, or whatever external tool, can use. But it can't be enforced at runtime in the language. much like type annotations... -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov