* Lint: Only ignore per-message links in Post-History with trailing slash
* PEP 684: Add trailing slash to per-message Post-History link
* Infra: Use clearer term (message, not post) for single Discourse messages
I had forgotten to update the Post-History header back in October. There was also one minor point from that round of discussion that I had not added to the PEP yet.
* Updates based on feedback
Adds explanation of handling `bin/` directory, or how we are not
trying to replace the existing virtual environments.
* Updates grammar based on feedback
Enforce the use of virtual environments and establish a conventional
name for the virtual environment directory.
Co-authored-by: Pradyun Gedam <pradyunsg@users.noreply.github.com>
Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
Co-authored-by: C.A.M. Gerlach <CAM.Gerlach@Gerlach.CAM>
Co-authored-by: Zak Johnson <me@zakj.net>
* Use #121212 for dark theme bgcolor
* Use #1111111 for dark theme bgcolor
Co-authored-by: C.A.M. Gerlach <CAM.Gerlach@Gerlach.CAM>
Co-authored-by: C.A.M. Gerlach <CAM.Gerlach@Gerlach.CAM>
* Rename `--without-gil` to `--disable-gil`.
Suggested by Inada Naoki.
* Add two sections to "Rejected Ideas":
- Why Not Deprecate ``PyDict_GetItem`` in Favor of ``PyDict_FetchItem``?
- Why Not Use PEP 683 Immortalization?
* Expand on Python build modes
The SVG image in the "Mind the Gap" section (pep-0495-gap.svg) was incorrect.
It is essentially the same as the the SVG image in the "In the Gap" section (pep-0495-fold.svg).
This is a bug that dates back to the original commit on
2015-08-30 (814d372811)
that uploaded the both the PNG and SVG versions of the Fold and Gap images.
The PNG version of the Gap image is correct, but the SVG version is incorrect.
The replacement SVG image attached in this PR is a manual recreation
of the PNG version of the Gap image that was deleted on 2022-04-23.
It is not exactly the same, but I think it is close enough.
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>
Petr Viktorin
Jelle Zijlstra
Kushal Das
Hugo van Kemenade
C.A.M. Gerlach
Eric Snow
Sagi Sarussi
Ralf Gommers
Steven Troxler
Pablo Galindo Salgado
Ken Jin
Pradyun Gedam
Sam Gross
Brian Park
Inada Naoki
Semnodime
Martin Fischer
T. Wouters
Łukasz Langa
James Hilton-Balfe
Adam Turner