iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

PEP 605: fix footnotes (#2743)

This commit is contained in:
Hugo van Kemenade 2022-07-29 12:46:20 +03:00 committed by GitHub
parent 3d63099a52
commit c75fd8f293
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 7 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
pep-0605.rst
View File

@ -508,7 +508,7 @@ full CPython C ABI:
built against the full CPython ABI in the preceding pre-release are expected
to load correctly, as long as those modules abide by the following additional
criteria:
* the module must not be using any provisional or private C APIs (either from
the previous stable release series, or the in development pre-release series)
that were removed in this beta release, or were changed in an ABI incompatible
@ -621,7 +621,7 @@ the X.Y.0 release.
Changes to management of the CPython stable C ABI
-------------------------------------------------
The CPython stable ABI [5_] makes the commitment that binary extension modules
The CPython stable ABI [5]_ makes the commitment that binary extension modules
built against any particular CPython release will continue to work on future
CPython releases that support the same stable ABI version (this version is
currently ``abi3``).
@ -752,7 +752,7 @@ On Windows systems, the suffix for tagged ``pyd`` files in pre-release builds
would include "p" as a pre-release marker immediately after the version number,
giving markers like "cp39p-win_amd64".
A proposed reference implementation for this change is available at [4_] (Note:
A proposed reference implementation for this change is available at [4]_ (Note:
at time of writing, that implementation had not yet been tested on Windows).
@ -911,12 +911,12 @@ final release.
Why not use Calendar Versioning for the rolling release stream?
---------------------------------------------------------------
Steve Dower's initial write-up of this proposal [1_] suggested the use of
Steve Dower's initial write-up of this proposal [1]_ suggested the use of
calendar versioning for the rolling release stream (so the first rolling
pre-release after Python 3.8.0 would have been Python 2019.12 rather than
3.9.0b1).
Paul Moore pointed out [2_] two major practical problems with that proposal:
Paul Moore pointed out [2]_ two major practical problems with that proposal:
* it isn't going to be clear to users of the calendar-based versions where they
stand in relation to the traditionally numbered versions
@ -1114,14 +1114,14 @@ Having a rolling pre-freeze release stream available may also make it more feasi
for more CI providers to offer a "CPython beta release" testing option. At the
moment, this feature is only available from CI providers that are willing and
able to put the necessary time and effort into creating, testing, and publishing
their own builds from the CPython master branch (e.g. [6_]).
their own builds from the CPython master branch (e.g. [6]_).
Implications for the proposed Scientific Python ecosystem support period
------------------------------------------------------------------------
Based on discussions at SciPy 2019, NEP (NumPy Enhancement Proposal) 29 has
been drafted [3_] to propose a common convention across the Scientific Python
been drafted [3]_ to propose a common convention across the Scientific Python
ecosystem for dropping support for older Python versions.
While the exact formulation of that policy is still being discussed, the draft
@ -1366,12 +1366,3 @@ Copyright
This document is placed in the public domain or under the CC0-1.0-Universal
license, whichever is more permissive.
..
Local Variables:
mode: indented-text
indent-tabs-mode: nil
sentence-end-double-space: t
fill-column: 80
coding: utf-8
End: