PEP 698: Tighten up the section about typing rules. (#2969)

In our original draft to PEP 698, we wanted to emphasize that the
PEP exclusively deals with `@override`, rather than adding new
rules about override type signature.

We did this by stating that compatibility rules were pre-existing.
This is true de-facto, because all type checkers implement at least
some compatibility checks, but upon a careful re-reading it turns out
compatibility checks on subclass methods are not specified in any
PEP.

As a result, we should simply state that this PEP is not adding
any new rules on signatures, without alluding to type checking
rules that are not specified in previous PEPs.

I will separately start a discussion in typing-sig about whether we
want to provide a paper trail in PEPs - either a new PEP or a
light amendment to PEP 484 - to make compatibility checks explicit.

Co-authored-by: Jelle Zijlstra <[email protected]>

Author: stroxler

pep-0698.rst

@@ -205,20 +205,13 @@ considers a method to be a valid override, which typically includes not only
 normal methods but also ``@property``, ``@staticmethod``, and ``@classmethod``.
 
 
-Override Compatibility Rules are Unchanged
-------------------------------------------
-
-Type checkers already enforce compatibility rules for overrides; for example, a
-subclass method’s type signature should be compatible with that of the
-superclass method. These compatibility rules do not change due to the presence
-or absence of ``@override``.
-
-Note that when a ``@property`` overrides a regular attribute of the base class,
-this should not be considered an error due to the use of ``@override``, but the
-type checker may still consider the override to be incompatible. For example a
-type checker may consider it illegal to override a non-final attribute with a
-getter property and no setter, as this does not respect the substitution
-principle.
+No New Rules for Override Compatibility
+---------------------------------------
+
+This PEP is exclusively concerned with the handling of the new ``@override`` decorator,
+which specifies that the decorated method must override some attribute in
+an ancestor class. This PEP does not propose any new rules regarding the type
+signatures of such methods.
 
 
 Strict Enforcement Per-Project