Skip to content

PEP 532, 577, 598: Fix footnotes references #2791

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 7 commits into from
Sep 14, 2022
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 3 additions & 13 deletions pep-0532.txt
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down Expand Up @@ -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
Expand All @@ -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:
17 changes: 3 additions & 14 deletions pep-0577.rst
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand All @@ -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:
Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -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:
18 changes: 4 additions & 14 deletions pep-0598.rst
Original file line number Diff line number Diff line change
Expand Up @@ -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.


Expand Down Expand Up @@ -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.

Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -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)
Expand All @@ -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: