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>
The prefix is very visible, so:
- No opt-in macro
- No new Include/ subdirectory
Removed frame evaluation API: I haven't found a way to use it,
so I can't test it.
Mention that unstable API should be documented and tested.
Add link to rough reference implementation.
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.
Ed Swierk
Ken Jin
Adam Turner
Philipp A
Steven Troxler
Jelle Zijlstra
Franek Magiera
Batuhan Taskaya
Pablo Galindo Salgado
Dane Hillard
Paul Moore
Hugo van Kemenade
Ezio Melotti
Petr Viktorin
Ee Durbin
Victor Stinner
Brett Cannon
T. Wouters
Łukasz Langa
Ned Deily
Václav Brožík
Matthew Rahtz
C.A.M. Gerlach
tk-woven
James Hilton-Balfe