How must @abc.abstractmethod be stacked with @property or @classmethod, and why?

### The rule `@abc.abstractmethod` goes **innermost** — directly above the `def` — and `@property`, `@classmethod` or `@staticmethod` goes outside it. Decorators apply bottom-up, so this order means `abstractmethod` receives the plain function, flags it, and hands it to the wrapper, which then wraps a function that is already marked. ```python class CatalogueSource(ABC): @property @abstractmethod def record_count(self): ... ``` ### Why the other order is an error, not a style choice `abc.abstractmethod` works by assigning `func.__isabstractmethod__ = True`. That works on a plain function, whose `__dict__` accepts arbitrary attributes. It does not work on a `property`, `classmethod` or `staticmethod` object: each of those types exposes `__isabstractmethod__` as a **read-only** computed attribute that reports `True` when any callable it wraps is abstract — the getter, setter and deleter for a `property`, the underlying function for the other two. Trying to assign it raises immediately, while the class body is still executing: ``` AttributeError: attribute '__isabstractmethod__' of 'property' objects is not writable ``` That is a genuinely nice failure: the wrong order blows up at import time rather than producing a class that silently is not abstract. Contrast that with the classic `@staticmethod` ordering bug of years past, where the wrong order simply produced something that never got flagged. ### What ABCMeta sees Because the wrapper reports abstractness for whatever it wraps, `ABCMeta` picks the name up normally: `sorted(CatalogueSource.__abstractmethods__)` is `['from_manifest', 'record_count']`, and instantiating `CatalogueSource` or any subclass that has not supplied both names raises `TypeError`. Nothing about the abstract-method mechanism changes; only the descriptor sitting on the class differs. A `property` is abstract if *any* of its three functions is abstract. In practice you mark the getter, and the whole descriptor is abstract: ```python class Source(ABC): @property @abstractmethod def record_count(self): ... @record_count.setter @abstractmethod def record_count(self, value): ... ``` Marking both is only worth doing when you actually want the setter documented as required; the abstract-name check cannot tell a subclass "you implemented the getter but not the setter", because it works on the name, not on the descriptor's parts. ### What a subclass has to provide Anything bound to that name. The natural implementation is a concrete `@property`, but because the check is presence-only, a plain class attribute satisfies it too: ```python class FileSource(CatalogueSource): record_count = 17 # satisfies the abstract property @classmethod def from_manifest(cls, manifest): return cls() ``` Both forms clear `__abstractmethods__`. This surprises people who expect the ABC to insist on a descriptor; it is the same "names, not contracts" property that ABCs have everywhere. If callers must be able to *set* the value, that is a review question, not something the machinery checks. For an abstract `classmethod`, the subclass supplies a real `classmethod`; for an abstract `staticmethod`, a real `staticmethod`. The ordering rule is identical in both cases and the same read-only `__isabstractmethod__` is what makes it so. ### The legacy helpers `abc.abstractproperty`, `abc.abstractclassmethod` and `abc.abstractstaticmethod` still exist and still import on 3.14, but they have been **deprecated since Python 3.3**, when stacking was made to work. They are single decorators that combine both roles. Seeing them in a code base is a dating clue rather than a bug, but writing them in new code is a small red flag: they do not compose, and the stacked form is what the documentation and every modern example use. ### The interview shape of this The question is usually asked as "what is wrong with this class?" over a snippet with `@abstractmethod` on top of `@property`. The complete answer names the failure (an `AttributeError` at class-definition time), the cause (`__isabstractmethod__` is writable on a function and read-only on the wrapper types), the fix (`abstractmethod` innermost), and the corollary that the wrapper computes its own abstractness from what it wraps — which is precisely why the correct order needs no special support from `ABCMeta` at all.