Skip to content

gh-119786: Fix typos in InternalDocs/frames.md #128275

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.

Sign up for GitHub

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 1 commit into from
Dec 26, 2024
Merged

gh-119786: Fix typos in InternalDocs/frames.md #128275

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
8 changes: 4 additions & 4 deletions InternalDocs/frames.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -33,7 +33,7 @@ Each activation record is laid out as:
* Stack

This seems to provide the best performance without excessive complexity.
The specials have a fixed size, so the offset of the locals is know. The
The specials have a fixed size, so the offset of the locals is known. The
interpreter needs to hold two pointers, a frame pointer and a stack pointer.

#### Alternative layout
Expand All @@ -52,7 +52,7 @@ an extra pointer for the locals, which can hurt performance.
### Generators and Coroutines

Generators and coroutines contain a `_PyInterpreterFrame`
The specials sections contains the following pointers:
The specials section contains the following pointers:

* Globals dict
* Builtins dict
Expand All @@ -69,7 +69,7 @@ and builtins, than strong references to both globals and builtins.

When creating a backtrace or when calling `sys._getframe()` the frame becomes
visible to Python code. When this happens a new `PyFrameObject` is created
and a strong reference to it placed in the `frame_obj` field of the specials
and a strong reference to it is placed in the `frame_obj` field of the specials
section. The `frame_obj` field is initially `NULL`.

The `PyFrameObject` may outlive a stack-allocated `_PyInterpreterFrame`.
Expand Down Expand Up @@ -128,7 +128,7 @@ The `return_offset` field determines where a `RETURN` should go in the caller,
relative to `instr_ptr`. It is only meaningful to the callee, so it needs to
be set in any instruction that implements a call (to a Python function),
including CALL, SEND and BINARY_SUBSCR_GETITEM, among others. If there is no
callee, then return_offset is meaningless. It is necessary to have a separate
callee, then return_offset is meaningless. It is necessary to have a separate
field for the return offset because (1) if we apply this offset to `instr_ptr`
while executing the `RETURN`, this is too early and would lose us information
about the previous instruction which we could need for introspecting and
Expand Down
Loading