- Some simple typo fixes.
- Harmonizing the code formatting of some functions & packages
- Some suggested punctuation changes
- Change to the external link to `overrides` package to allow code formatting in the link
- Converting uses of "get" to "set" when referring to adding `__override__`
to decorated objects, for semantic consistency
Co-authored-by: C.A.M. Gerlach <CAM.Gerlach@Gerlach.CAM>
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>
* PEP 698: discuss.python.org thread to post-history
As far as I know this is the last update needed ahead of SC
review.
* Also change the Discussions-To header
We claimed that there are two disadvantages to overrides:
it makes code more verbose, and requires developers to update
subclasses when possibly-breaking changes happen to base classes.
In discussion, it was pointed out that the second disadvantage is
kind of strange - it is exactly the same as the advantage of
using @override in the first place because the whole point is that
it is not usually safe to assume subclasses can be unchanged when
a method they override is removed from a base class.
I think just pointing out verbosity is good enough, I think it's
understood that more verbose code potentially requires more edits
to change, and in reality I think the case when it was safe to
ignore invalidated overrides is pretty rare so making that a big
focus seems a little weird.
At this time, Pyre still does not have strict override enforcement.
This (and supporting codemod tools) are still something we want,
but given that we have not yet delivered this and do not have a firm
ETA we should not make claims about specific plans in the PEP text.
We decided to add this for two reasons:
- It was specifically requested by the author of the `overrides`
library, because there there are some handy runtime uses
of override information (such as propagating docstrings, which
we highlight as a concrete example)
- We realized that we actually added `__final__` to
`@typing.final` in spite of it not being specified in PEP 591,
which we felt strongly suggests that even if we omit it we
would later change our minds.
This runtime behavior is currently implemented in typing_extensions
(see https://github.com/python/typing_extensions/pull/86) as well
as pyre_extensions.
Brian Skinn
Steven Troxler
tk-woven
Brett Cannon
Mikko Korpela
Jelle Zijlstra
Zachary Blackwood