iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

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 <jelle.zijlstra@gmail.com>
This commit is contained in:
Steven Troxler 2023-01-18 08:33:42 -08:00 committed by GitHub
parent d525d4db6a
commit c582627501
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 6 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
pep-0698.rst
View File

@ -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
------------------------------------------
No New Rules for Override Compatibility
---------------------------------------
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.
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