On Thu, Dec 5, 2013 at 6:08 PM, Allen Li <cyberdup...@gmail.com> wrote: > On Thu, Dec 05, 2013 at 01:33:00PM -0800, Guido van Rossum wrote: >> > The only two alternatives are doing nothing/pass/return >> > None or having actual code in the method. >> > >> > The former is only useful to silently ignore blind super() calling, the >> > latter you would define and decorate the method normally. >> >> Actually if you want to support multiple inheritance of your ABC, your >> abstract methods *must* be no-ops (or have some kind of default >> behavior that can always be done last). > > I must respectfully disagree with this. If your ABCs aren't meant to be > in the MRO, then you should be @registering them as virtual classes and > not inheriting them.
Registering is meant to be a method of last resort; it is implemented for cases where an ABC is introduced after implementations already exist (IOW, formalizing duck typing). When the ABC *is* actually used as a base class, when the standard M.I. patterns are used, the abstract methods must be no-ops, because they will be called (last). > The trick with Python multiple inheritance and super() (from personal > experience) is to not think of it as multiple inheritance (a tree with > cycles), but as building the MRO (linear, the same as single > inheritance). I'm not sure I understand -- or maybe I disagree. "A tree with cycles" seems a really poor way to describe what is usually referred to as a "diamond inheritance diagram". The right patterns require that you design your class to be unaware of the exact MRO. But we're getting off-topic. You should probably read one of the standard tutorials on the topic to refresh your use of the terminology. -- --Guido van Rossum (python.org/~guido) _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
