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>
Sponsor: Łukasz Langa <lukasz at python.org>
Co-authored-by: Hugo van Kemenade <hugovk@users.noreply.github.com>
Co-authored-by: Qexat <43090614+qexat@users.noreply.github.com>
Since inversion doesn’t just affect brightness, but also hue, there’s a problem: Some background colors have perceptually less contrast with their text when hue rotated. This rotates their hue back, fixing the contrast issue.
* 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
When the author cancels a PEP, it's Withdrawn. The SC does rejections.
Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
Co-authored-by: C.A.M. Gerlach <CAM.Gerlach@Gerlach.CAM>
* PEP 485: Fix relative difference formula
The formula did not work correctly for negative (a+b) values.
* PEP 485: Fix grammatical typo
Grammatical typo close to the formula typo.
* PEP 697: Changes based on initial implementation & docs
- Use a flag, `Py_TPFLAGS_ITEMS_AT_END`, rather than a slot. This way the subclass doesn't need to worry about items (if the superclass is set up right).
- The result of `PyObject_GetTypeDataSize` may be higher than requested by -basicsize (e.g. due to alignment). It is safe to use all of it (e.g. with memset).
- Mention that `basicsize == 0` and `itemsize == 0` already work. I’ll add explicit docs & tests though.
- Add link to initial implementation
- Add endorsements
- Add a “big picture” decision tree
- Rewording
- Mention possible flags for alternative item layouts
* Apply suggestions from code review
Co-authored-by: C.A.M. Gerlach <CAM.Gerlach@Gerlach.CAM>