From 01473dc8d0cbe871b0338a4228d31b1bf353a6d3 Mon Sep 17 00:00:00 2001 From: Hugo van Kemenade Date: Wed, 14 Sep 2022 11:35:00 +0300 Subject: [PATCH] PEP 532, 577, 598: Fix footnotes references (#2791) --- pep-0532.txt | 16 +++------------- pep-0577.rst | 17 +++-------------- pep-0598.rst | 18 ++++-------------- 3 files changed, 10 insertions(+), 41 deletions(-) diff --git a/pep-0532.txt b/pep-0532.txt index 5a67830b3..9b974a8d0 100644 --- a/pep-0532.txt +++ b/pep-0532.txt @@ -107,7 +107,7 @@ PEP 335: Overloadable Boolean operators comparison chaining being one of the consequences of that change. The proposal in an earlier version of this PEP to instead handle the element-wise comparison use case by changing the semantic definition of comparison chaining -is drawn directly from Guido's rejection of :pep:`335` [1_]. +is drawn directly from Guido's rejection of :pep:`335` [1]_. However, initial feedback on this PEP indicated that the number of different proposals that it covered made it difficult to read, so that part of the @@ -875,9 +875,9 @@ interest in the idea of making these changes. Acknowledgements ================ -Thanks go to Steven D'Aprano for his detailed critique [2_] of the initial +Thanks go to Steven D'Aprano for his detailed critique [2]_ of the initial draft of this PEP that inspired many of the changes in the second draft, as -well as to all of the other participants in that discussion thread [3_] +well as to all of the other participants in that discussion thread [3]_. References @@ -897,13 +897,3 @@ Copyright This document has been placed in the public domain under the terms of the CC0 1.0 license: https://creativecommons.org/publicdomain/zero/1.0/ - - -.. - Local Variables: - mode: indented-text - indent-tabs-mode: nil - sentence-end-double-space: t - fill-column: 70 - coding: utf-8 - End: diff --git a/pep-0577.rst b/pep-0577.rst index 13e2568a2..91684a025 100644 --- a/pep-0577.rst +++ b/pep-0577.rst @@ -490,7 +490,7 @@ Ignoring scoped expressions when determining augmented assignment targets ------------------------------------------------------------------------- When discussing possible binding semantics for :pep:`572`'s assignment expressions, -Tim Peters made a plausible case [1_,2_,3_] for assignment expressions targeting +Tim Peters made a plausible case [1]_, [2]_, [3]_ for assignment expressions targeting the containing block scope, essentially ignoring any intervening scoped expressions. @@ -505,7 +505,7 @@ way:: while any(n % (factor := p) == 0 for p in small_primes): n //= factor -Guido also expressed his approval for this general approach [4_]. +Guido also expressed his approval for this general approach [4]_. The proposal in this PEP differs from Tim's original proposal in three main areas: @@ -536,7 +536,7 @@ One of the challenges with :pep:`572` is the fact that ``NAME = EXPR`` and makes the two forms hard to teach, since there's no inherent nudge towards choosing one over the other at the statement level, so you end up having to resort to "``NAME = EXPR`` is preferred because it's been around longer" -(and :pep:`572` proposes to enfore that historical idiosyncrasy at the compiler +(and :pep:`572` proposes to enforce that historical idiosyncrasy at the compiler level). That semantic equivalence is difficult to avoid at module and class scope while @@ -820,14 +820,3 @@ Copyright ========= This document has been placed in the public domain. - - - -.. - Local Variables: - mode: indented-text - indent-tabs-mode: nil - sentence-end-double-space: t - fill-column: 70 - coding: utf-8 - End: diff --git a/pep-0598.rst b/pep-0598.rst index e36fea94f..0271d56a8 100644 --- a/pep-0598.rst +++ b/pep-0598.rst @@ -36,7 +36,7 @@ proposal in :pep:`605`. However, the concerns raised in this PEP are likely to apply to any other "Long Term Support branch" proposals that allow feature backports to improve the developer experience of supporting such releases (such as the EL Python -draft at [3_]), so the ideas presented here may provide useful design +draft at [3]_), so the ideas presented here may provide useful design suggestions for such proposals. @@ -612,7 +612,7 @@ in that release series. Implications for the proposed Scientific Python ecosystem support period ------------------------------------------------------------------------ -Based on discussions at SciPy 2019, a NEP is currently being drafted [2_] to +Based on discussions at SciPy 2019, a NEP is currently being drafted [2]_ to define a common convention across the Scientific Python ecosystem for dropping support for older Python versions. @@ -833,7 +833,7 @@ the subsequent October 2022 baseline feature release, as there are already inher compatibility risks associated with the choice of either "Python 4.0" (erroneous checks for the major version being exactly 3 rather than 3 or greater), or "Python 3.10" (code incorrectly assuming that the minor version will always -contain exactly one decimal digit) [1_]. +contain exactly one decimal digit) [1]_. While the text of this PEP assumes that the release published in 2022 will be 3.10 (as the PEP author personally considers that the more reasonable and most @@ -883,7 +883,7 @@ References ========== .. [1] Anthony Sottile created a pseudo "Python 3.10" to find and fix such issues - (https://github.com/asottile/python3.10) + (https://github.com/asottile-archive/python3.10) .. [2] NEP proposing a standard policy for dropping support of old Python versions (https://github.com/numpy/numpy/pull/14086) @@ -895,13 +895,3 @@ Copyright ========= This document has been placed in the public domain. - - -.. - Local Variables: - mode: indented-text - indent-tabs-mode: nil - sentence-end-double-space: t - fill-column: 80 - coding: utf-8 - End: