Clarify Windows support phases
This isn't a semantic change, but I just got "extended support" and "extended security updates" confused and Steve Dower had to correct me. So make it even more obvious in the text that we mean "extended support", and not "extended security updates".
* Replace StandardError with Exception to avoid confusion when using
the DB-API 2.0 in the context of Python 3.
Add a note about a future upgrade to the Warning base class.
Fixes#2776.
* Fix typo and add year for more context.
* Remove mention of the exceptions module
This was removed in Python 3 as well. Python 2.7 doesn't need it either,
since all standard exceptions are builtin objects.
* Remove mention of exception objects being builtins.
They were already for a very long time, so this is pointless.
I only had this sentence to explain why I had removed the
"import exceptions" line from the Python 2 days.
* Grammar fix
* Fix exception hierarchy formatting
* PEP 550: Remove orphaned references
* PEP 550: Remove redundant emacs metadata
* PEP 550: Use plaintext literal block for ASCII diagram
* PEP 550: Update links
* PEP 550: Clean up link
Co-authored-by: CAM Gerlach <CAM.Gerlach@Gerlach.CAM>
Co-authored-by: CAM Gerlach <CAM.Gerlach@Gerlach.CAM>
As originally discussed in #2692 , this adds a three new custom directives intended to be used at the top of PEPs:
* `pep-banner`, a generic admonition banner that can be subclassed with an arbitrary message,
* `canonical-docs`, which renders a banner linking to a `Final` PEP's canonical documentation/specification.
* `canonical-pypa-spec`, a banner for packaging interoperability PEPs linking to the canonical PyPA specs.
Co-authored-by: Hugo van Kemenade <hugovk@users.noreply.github.com>
Substantive content changes:
* Instead of adding a new top-level `license-expression` key for the license expression in the `[project]` table of the `pyproject.toml` source metadata, the PEP now specifies using the top-level string value of the `license` key for this purpose, which PEP 621 (PEP-621) reserved it for, and updates the `license-expression` and `license` key specs, and the examples, rejected ideas and other sections accordingly.
* Since this makes it not possible to convert a legacy `license` key to the new `License-Expression` field at build time, and that's not really advisable anyway, it drastically simplifies the normative Converting Legacy Metadata section to just a single normative statement, and updates/removes other mentions of it accordingly, and the (already rather unhelpful) example
* Likewise, it simplifies and refines the guidance in the Mapping classifiers to SPDX identifiers section to be more general and less focused on build time, and also allows tools to ignore redundant parent classifiers (Note: This section will be moved to an external appendix in the next PR, but I didn't move it here for ease of review)
* The `license_files` directory was renamed to `licenses` at the request of @brettcannon and to simplify things a touch
* The specified handling of the `license.file` key was a bit confused by a (apparently quite common) misunderstanding about how the specified file is used (to inject its text directly under the `License` field in core metadata, rather than included in distribution archives or its path specified in metadata) due to it being rather underspecified in PEP 621, which this revision corrects.
* Bump the core metadata version to reflect acceptance of PEP 685 as Metadata 2.3
* Bump the SPDX license list version to be up to date
Significant non-normative/editorial changes:
* Mention implementation of drafts of this PEP in Hatch and Setuptools, and also describes previous efforts in Setuptools and Wheel that this PEP builds on more clearly, as suggested on the discussion thread
* Reference the canonical project [source] metadata PyPA spec instead of PEP 621, use clearer language surrounding that, and update a few references to other PEPs
* Revise the Motivations and Rationale to be less duplicative/redundant, more balanced and focused more specifically on their respective areas (providing some background and describing the problem, and introducing and justifying the proposed solution, respectively)
* Add a short blurb making explicit the use of RFC 2119 terminology (MUST, SHOULD, etc)
* Update PEP headers
* Various other minor revisions to correct typos and other issues, clarify and simply the text, and improve source formatting.
Eric Snow
Nathaniel J. Smith
Brett Cannon
Steven Troxler
Mark Shannon
Franek Magiera
C.A.M. Gerlach
Paul Moore
Hugo van Kemenade
Victor Stinner
Sebastián Ramírez
Eric Traut
Shantanu
Pablo Galindo Salgado
Tal Einat
Ned Deily
Łukasz Langa
Marc-Andre Lemburg
Petr Viktorin
KotlinIsland
Zac Hatfield-Dodds
Kushal Das
Kebap