@@ -391,22 +391,26 @@ High-level APIs
391391 .. versionadded :: 3.9
392392
393393
394- .. c :function :: void _PyInterpreterState_SetEvalFrameFunc (PyInterpreterState *interp, _PyFrameEvalFunction eval_frame, int allow_specialization )
394+ .. c :function :: void _PyInterpreterState_SetEvalFrameFunc (PyInterpreterState *interp, _PyFrameEvalFunction eval_frame)
395395
396396 Set the frame evaluation function.
397397
398- If *allow_specialization * is non-zero, the adaptive specializer will
399- continue to specialize bytecodes even though a custom eval frame function
400- is set. When *allow_specialization * is zero, setting a custom eval frame
401- disables specialization.
402-
403398 See the :pep: `523 ` "Adding a frame evaluation API to CPython".
404399
405400 .. versionadded :: 3.9
406401
407- .. versionchanged :: 3.15
408- Added the *allow_specialization * parameter.
402+ .. c :function :: void _PyInterpreterState_SetEvalFrameAllowSpecialization (PyInterpreterState *interp, int allow_specialization)
403+
404+ Enables or disables specialization why a custom frame evaluator is in place.
409405
406+ If *allow_specialization * is non-zero, the adaptive specializer will
407+ continue to specialize bytecodes even though a custom eval frame function
408+ is set. When *allow_specialization * is zero, setting a custom eval frame
409+ disables specialization. The standard interpreter loop will continue to deopt
410+ while a frame evaluation API is in place - the frame evaluation function needs
411+ to handle the specialized opcodes to take advantage of this.
412+
413+ .. versionadded :: 3.15
410414
411415.. c :function :: int _PyInterpreterState_IsSpecializationEnabled (PyInterpreterState *interp)
412416
0 commit comments