Checking for abstractmethod implementation fails to consider MRO for builtins #79244

Activity

1. anntzer commented on Oct 25, 2018

   

   anntzermannequin

   on Oct 25, 2018

   MannequinAuthor

   More actions

   When checking whether a class implements all abstractmethods (to know whether the class can be instantiated), one should only consider methods that come *before* the abstractmethod in the MRO -- methods that come after cannot be said to override the abstractmethod. Indeed, this is currently the case:

       from abc import ABC, abstractmethod
   
       class NeedsFoo(ABC):
           foo = abstractmethod(lambda self: None)
   
       class HasFoo(ABC):
           foo = lambda self: None
   
       class FooImplFirst(HasFoo, NeedsFoo): pass
       class FooImplSecond(NeedsFoo, HasFoo): pass
   
       FooImplFirst()
       try: FooImplSecond()
       except TypeError: pass
       else: raise Exception("Expected error")

   Here FooImplFirst correctly overrides the foo method (using the HasFoo mixin first), so can be instantiated; FooImplSecond doesn't (by the MRO, FooImplSecond().foo would resolve to the abstract implementation), and we get a TypeError on instantiation.

   However, this is not the case when considering builtins:

       from abc import ABC, abstractmethod
   
       class NeedsKeys(ABC):
           keys = abstractmethod(lambda self: None)
   
       HasKeys = dict  # dict has a keys method.
   
       class KeysImplFirst(HasKeys, NeedsKeys): pass
       class KeysImplSecond(NeedsKeys, HasKeys): pass
   
       KeysImplFirst()
       try: KeysImplSecond()
       except TypeError: pass
       else: raise Exception("Expected error")

   This example differs from the first only by having dict be the mixin that provides the keys method. However, running this example shows that KeysImplSecond() will incorrectly succeed: the ABC machinery does not realize that the keys method has not been overridden.

   (Alternatively, one could say that "providing the method later in the MRO" is also sufficient; I think that goes against the expectations about ABCs but at least consistency between the non-builtin and builtin cases would be better.)
2. anntzer

   added

   3.7 (EOL)end of lifeend of life

   stdlibStandard Library Python modules in the Lib/ directoryStandard Library Python modules in the Lib/ directory

   on Oct 25, 2018
3. iritkatriel commented on Dec 6, 2021

   

   iritkatriel

   on Dec 6, 2021

   Member

   More actions

   See also bpo-37927.
4. iritkatriel

   added

   3.9 (EOL)end of lifeend of life

   3.10 (EOL)end of lifeend of life

   3.11only security fixesonly security fixes

   type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

   and removed

   3.7 (EOL)end of lifeend of life

   on Dec 6, 2021
5. ezio-melotti

   transferred this issue fromon Apr 10, 2022