PEP 698: Include discussion of pinning the ancestor class

pep-0698.rst

@@ -418,6 +418,53 @@ hands of project owners, whereas the use of ``@require_explicit_overrides`` in
 libraries would force project owners to use ``@override`` even if they prefer
 not to.
 
+Include the name of the ancestor class being overridden
+-------------------------------------------------------
+
+We considered allowing the caller of ``@override`` to specify a specific
+ancestor class where the overridden method should be defined:
+
+.. code-block:: python
+
+    class Parent0:
+        def foo() -> int:
+            return 1
+
+
+    class Parent1:
+        def bar() -> int:
+            return 1
+
+
+    class Child(Parent0, Parent1):
+        @override(Parent0)  # okay, Parent0 defines foo
+        def foo() -> int:
+            return 2
+
+        @override(Parent0)  # type error, Parent0 does not define bar
+        def bar() -> int:
+            return 2
+
+
+This could be useful for code readability because it makes the override
+structure more explicit for deep inheritance trees. It also might catch bugs by
+prompting developers to check that the implementation of an override still makes
+sense whenever a method being overridden moves from one base class to another.
+
+We decided against it because:
+
+- Supporting this would add complexity to the implementation of both
+  ``@override`` and type checker support for it, so there would need to
+  be considerable value add.
+- We believe that it would be rarely used and catch relatively few bugs.
+
+  - The author of the ``overrides`` package
+    `has noted <https://discuss.python.org/t/pep-698-a-typing-override-decorator/20839/4>`_
+    that early versions of his library included this capability but it was
+    rarely useful and seemed to have little benefit. After it was removed, the
+    ability was never requested by users.
+
+
 
 Reference Implementation
 ========================