bpo-44964: Add a note explaining the new semantics of f_last_i in frame objects (GH-28200)

(cherry picked from commit fa2c0b85a8)

Co-authored-by: Pablo Galindo Salgado <Pablogsal@gmail.com>
This commit is contained in:
Miss Islington (bot) 2021-09-07 04:36:43 -07:00 committed by GitHub
parent 608a629236
commit fc840736e5
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
2 changed files with 9 additions and 2 deletions

View file

@ -1034,8 +1034,9 @@ Internal types
:attr:`f_code` is the code object being executed in this frame; :attr:`f_locals`
is the dictionary used to look up local variables; :attr:`f_globals` is used for
global variables; :attr:`f_builtins` is used for built-in (intrinsic) names;
:attr:`f_lasti` gives the precise instruction (this is an index into the
bytecode string of the code object).
:attr:`f_lasti` gives the precise instruction (it represents a wordcode index, which
means that to get an index into the bytecode string of the code object it needs to be
multiplied by 2).
Accessing ``f_code`` raises an :ref:`auditing event <auditing>`
``object.__getattr__`` with arguments ``obj`` and ``"f_code"``.

View file

@ -1944,6 +1944,12 @@ Changes in the C API
source_buf = PyBytes_AsString(source_bytes_object);
code = Py_CompileString(source_buf, filename, Py_file_input);
* For ``FrameObject`` objects, the ``f_lasti`` member now represents a wordcode
offset instead of a simple offset into the bytecode string. This means that this
number needs to be multiplied by 2 to be used with APIs that expect a byte offset
instead (like :c:func:`PyCode_Addr2Line` for example). Notice as well that the
``f_lasti`` member of ``FrameObject`` objects is not considered stable.
CPython bytecode changes
========================