PEP 651 rejected by the SC (#1864)

pep-0651.rst

@@ -1,13 +1,20 @@
 PEP: 651
 Title: Robust Stack Overflow Handling
 Author: Mark Shannon <mark@hotpy.org>
-Status: Draft
+Status: Rejected
 Type: Standards Track
 Content-Type: text/x-rst
 Created: 18-Jan-2021
 Post-History: 19-Jan-2021
 
 
+Rejection Notice
+================
+
+This PEP has been `rejected by the Python Steering Council
+<https://mail.python.org/archives/list/python-dev@python.org/thread/75BFSBM5AJWXOF5OSPLMJQSTP3TDOKRP/>`_.
+
+
 Abstract
 ========
 
@@ -41,7 +48,7 @@ Motivation
 
 CPython uses a single recursion depth counter to prevent both runaway recursion and C stack overflow.
 However, runaway recursion and machine stack overflow are two different things.
-Allowing machine stack overflow is a potential security vulnerability, but limiting recursion depth can prevent the 
+Allowing machine stack overflow is a potential security vulnerability, but limiting recursion depth can prevent the
 use of some algorithms in Python.
 
 Currently, if a program needs to deeply recurse it must manage the maximum recursion depth allowed,
@@ -89,7 +96,7 @@ so any code that handles ``RecursionError`` will continue to work as before.
 Decoupling the Python stack from the C stack
 --------------------------------------------
 
-In order to provide the above guarantees and ensure that any program that worked previously 
+In order to provide the above guarantees and ensure that any program that worked previously
 continues to do so, the Python and C stack will need to be separated.
 That is, calls to Python functions from Python functions, should not consume space on the C stack.
 Calls to and from builtin functions will continue to consume space on the C stack.
@@ -109,7 +116,7 @@ Other Implementations
 Other implementations are required to fail safely regardless of what value the recursion limit is set to.
 
 If the implementation couples the Python stack to the underlying VM or hardware stack,
-then it should raise a ``RecursionOverflow`` exception when the recursion limit is exceeded, 
+then it should raise a ``RecursionOverflow`` exception when the recursion limit is exceeded,
 but the underlying stack does not overflow.
 If the underlying stack overflows, or is near to overflow,
 then a ``StackOverflow`` exception should be raised.
@@ -146,7 +153,7 @@ Some low-level tools, such as machine-code debuggers, will need to be modified.
 For example, the gdb scripts for Python will need to be aware that there may be more than one Python frame
 per C frame.
 
-C code that uses the ``Py_EnterRecursiveCall()``, ``PyLeaveRecursiveCall()`` pair of 
+C code that uses the ``Py_EnterRecursiveCall()``, ``PyLeaveRecursiveCall()`` pair of
 functions will continue to work correctly. In addition, ``Py_EnterRecursiveCall()``
 may raise a ``StackOverflow`` exception.
 
@@ -185,9 +192,9 @@ We need to determine a safe bounds for the stack, which is not something possibl
 
 For major platforms, the platform specific API will be used to provide an accurate stack bounds.
 However, for minor platforms some amount of guessing may be required.
-While this might sound bad, it is no worse than the current situation, where we guess that the 
+While this might sound bad, it is no worse than the current situation, where we guess that the
 size of the C stack is at least 1000 times the stack space required for the chain of calls from
-``_PyEval_EvalFrameDefault`` to ``_PyEval_EvalFrameDefault``. 
+``_PyEval_EvalFrameDefault`` to ``_PyEval_EvalFrameDefault``.
 
 This means that in some cases the amount of recursion possible may be reduced.
 In general, however, the amount of recursion possible should be increased, as many calls will use no C stack.