Exercises — Abstract base classes — ABC module, `@abstractmethod`

• (a) NOT abstract. A decorates f with @abstractmethod but ==does not inherit ABC==. The decorator only tags the function; the blocking is done by the metaclass ABCMeta, which arrives with ABC. Since A's metaclass is the ordinary type, nobody ever reads the tag (and no __abstractmethods__ checklist is even stapled on). A() succeeds.
• (b) ABSTRACT. B inherits ABC and has an @abstractmethod. So B.__abstractmethods__ = frozenset({'f'}), which is non-empty → B() raises TypeError.
• (c) NOT abstract. C inherits ABC but has zero abstract methods (f is a normal method). C.__abstractmethods__ = frozenset() (empty, i.e. ∅) → C() works fine.

Rule check: abstract requires both ingredients — ABC (the enforcer) and at least one live @abstractmethod (something to enforce).

False. Inheriting ABC only enables the check. If the class has no abstract methods, __abstractmethods__ is empty and it instantiates normally (see 1.1c). ABC is the referee; you still need at least one @abstractmethod for there to be a foul.

class Rectangle(Shape):
    def __init__(self, w, h):
        self.w = w
        self.h = h
    def area(self):
        return self.w * self.h
 
Rectangle(4, 5).area()   # 20

Why it works: Rectangle overrides area (redefines it in its own body). The metaclass subtracts area from the inherited checklist → Rectangle.__abstractmethods__ is empty (∅) → instantiation allowed. Answer: $4\times 5=20$.

class Circle(Shape):
    def __init__(self, r):
        self.r = r
    def area(self):
        return 3.14159 * self.r ** 2
 
Circle(3).area()   # 28.27431

Why: override area → contract cleared. $3.14159\times 3^2=3.14159\times 9=28.27431$.

No — Blob() raises TypeError. Re-tagging area with @abstractmethod puts it back into Blob.__abstractmethods__. Even though it has a body (return 0), the presence of the tag means "this is still a blank to be filled by my subclasses." Blob is therefore abstract again. A body does not cancel abstractness — only removing the tag on override does.

The checklist is recomputed at each class definition: start from the parent's checklist, remove any name this class overrides with a non-abstract method, add any new @abstractmethod.

• A.__abstractmethods__ = frozenset({'f', 'g'}) — both declared abstract, neither implemented.
• B.__abstractmethods__ = frozenset({'g'}) — B overrides f (removes f); g is still inherited-but-unimplemented, so it survives. B is still abstract.
• C.__abstractmethods__ = frozenset() (∅) — C overrides g, and f was already cleared by B. Empty set.
• So C() → prints "C built".

Now trace it in the figure below: watch the checklist shrink one name at a time as we descend, and see the exact level where it first becomes empty (∅) and the gate finally opens.

B is NOT instantiable. B.__abstractmethods__ = {'g'} is non-empty. B() raises: TypeError: Can't instantiate abstract class B with abstract method g. The message names exactly the surviving method (g) — this is the "fail loud, name the blank" behaviour the whole ABC machinery buys you.

from abc import ABC, abstractmethod
 
class Employee(ABC):
    @property
    @abstractmethod
    def salary(self): ...
 
    @abstractmethod
    def role(self): ...
 
class Manager(Employee):
    @property
    def salary(self):
        return 90000
    def role(self):
        return "manager"
 
m = Manager()
m.salary   # 90000
m.role()   # "manager"

Why the decorator order? @property must be outermost (top), @abstractmethod innermost (touching def). Reason: @abstractmethod needs to tag the raw function before property wraps it. If the tag sat on the outside, property — not your method — would be marked abstract, and the abstractness could leak away. This ordering is the same idea used in Polymorphism where the interface shape matters more than the storage.

from abc import ABC, abstractmethod
 
class Factory(ABC):
    @classmethod
    @abstractmethod
    def build(cls): ...
 
    @staticmethod
    @abstractmethod
    def spec(): ...
 
class WidgetFactory(Factory):
    @classmethod
    def build(cls):
        return "widget"
    @staticmethod
    def spec():
        return "spec-v1"
 
WidgetFactory.build()   # "widget"
WidgetFactory.spec()    # "spec-v1"

Correct order: @classmethod (or @staticmethod) outermost/top, @abstractmethod innermost/bottom, touching def — exactly like @property. The reason is identical: @abstractmethod must tag the raw underlying function first, and only then may classmethod/staticmethod wrap that tagged function. What breaks with the wrong order (@abstractmethod on top of @classmethod): the abstract tag would land on the already-wrapped classmethod object rather than the raw function, so the name may not land in __abstractmethods__ — the abstractness silently disappears and a subclass forgetting build would slip through the gate. (Modern CPython special-cases some of this, but the safe, portable rule is always: @abstractmethod innermost.)

from abc import ABC, abstractmethod
 
class Logger(ABC):
    @abstractmethod
    def write(self, msg):
        return f"[log] {msg}"
 
class FileLogger(Logger):
    def write(self, msg):
        base = super().write(msg)     # reuse abstract method's body
        return base + " -> file"
 
FileLogger().write("hi")   # "[log] hi -> file"

Why this is legal: @abstractmethod forces the override but does not forbid a body. FileLogger overrides write (clearing the checklist → instantiable), then chooses to call the parent's body with super(). Abstract ≠ empty. Result: "[log] hi -> file".

Impl() SUCCEEDS. Python's ABC machinery checks only that the name send is overridden with a non-abstract method — it does not compare parameter lists. Impl.__abstractmethods__ is empty (∅), so the object builds. The mismatch only explodes later, when someone calls impl.send("hi", True) and gets a TypeError: send() takes 1 positional argument but 3 were given. Reveal: ABCs enforce presence of a name, not signature compatibility. For signature checking you need a static type checker (mypy) or Protocols (typing.Protocol).

It builds. Empty inherits ABC but declares no abstract methods, so Empty.__abstractmethods__ = frozenset() (empty, ∅). By the rule $\text{can\_instantiate}(C)⟺\text{\_\_abstractmethods\_\_}=\varnothing$, empty checklist → instantiable. Inheriting ABC is necessary but not sufficient for abstractness; you also need a live blank.

checkout runs fine — at call time Python only needs the object to have a callable pay (Duck Typing vs Nominal Typing: "if it quacks, it's a duck"). The plain function checkout(p, amt) never checks type, only behaviour. Contrast: the ABC's guarantee is different in kind. An ABC + a p: PaymentProcessor type hint promises, at construction time of every subclass, that pay exists — a nominal (name/inheritance-based) guarantee checked early and loudly. Duck typing checks structurally and lazily (only when pay is actually called). ABCs move the failure earlier; duck typing tolerates any object that fits. Same goal (safe p.pay(amt)), different enforcement moment. See Interfaces in other languages for how other languages make this nominal check mandatory.

• issubclass(Sprite, Drawable) → True. register makes Sprite a virtual subclass for the purposes of issubclass/isinstance.
• isinstance(Sprite(), Drawable) → True for the same reason.
• Sprite().draw() → "drawn" — it's an ordinary method on an ordinary class.

What register does NOT do: it does not check that Sprite actually implements draw. You could register a class with no draw at all and isinstance would still say True, then crash when you call draw(). register is a promise you make, not a check Python performs — the opposite trade-off from normal ABC enforcement. Details in Metaclasses and ABCMeta.