PEP 651: Clarifications, as suggested by GvR. (#1775)

pep-0651.rst

@@ -124,6 +124,8 @@ Py_CheckStackDepth()
 ``int Py_CheckStackDepth(const char *where)``
 will return 0 if there is no immediate danger of C stack overflow.
 It will return -1 and set an exception, if the C stack is near to overflowing.
+The ``where`` parameter is used in the exception message, in the same fashion
+as the ``where`` parameter of ``Py_EnterRecursiveCall()``.
 
 Py_EnterRecursiveCall()
 '''''''''''''''''''''''
@@ -174,8 +176,8 @@ but it is quite likely that the net effect will be too small to be measured.
 Implementation
 ==============
 
-Notes
------
+Monitoring C stack consumption
+------------------------------
 
 Gauging whether a C stack overflow is imminent is difficult. So we need to be conservative.
 We need to determine a safe bounds for the stack, which is not something possible in portable C code.
@@ -192,6 +194,19 @@ In general, however, the amount of recursion possible should be increased, as ma
 Our general approach to determining a limit for the C stack is to get an address within the current C frame,
 as early as possible in the call chain. The limit can then be guessed by adding some constant to that.
 
+Making Python-to-Python calls without consuming the C stack
+-----------------------------------------------------------
+
+Calls in the interpreter are handled by the ``CALL_FUNCTION``,
+``CALL_FUNCTION_KW``, ``CALL_FUNCTION_EX`` and ``CALL_METHOD`` instructions.
+The code for those instructions will be modified so that when
+a Python function or method is called, instead of making a call in C,
+the interpreter will setup the callee's frame and continue interpretation as normal.
+
+The ``RETURN_VALUE`` instruction will perform the reverse operation,
+except when the current frame is the entry frame of the interpreter
+when it will return as normal.
+
 
 Rejected Ideas
 ==============