Compare CPython versions

Use the CPython dependency inventory to scope this work. Resolve exact old/new tags or commits; distinguish a release tag from a moving development branch. Use an existing CPython checkout when available, or a separate checkout of https://github.com/python/cpython. Do not switch the user's working checkout to inspect another ref.

Run in the CPython checkout, substituting verified refs and paths:

git diff <old-ref> <new-ref> -- <relevant-header-or-source>
git log <old-ref>..<new-ref> -- <relevant-header-or-source>
git log -p <old-ref>..<new-ref> -S '<changed-symbol>' -- Include Python Objects Modules

Use the inventory to check these change categories; this is not an exhaustive compatibility checklist:

• Struct fields added, removed, renamed, reordered, or retyped, including pointer-to-tagged-reference changes, bitfields, alignment, and offsets used by copied layouts.
• Headers or declarations moved, split, or merged; changed include order, guards, and build macros.
• Functions or macros added, removed, or deprecated; changed signatures, replacements, and contracts.

For local examples, inspect ddtrace/internal/datadog/profiling/profiling_helpers/version_compat.h and frame_accessors.h in that directory: they handle moved interpreter-frame headers and different representations of the frame's executable field. Verify each comparison against the selected versions.

Inspect implementations as well as declarations: layouts, ownership, GIL requirements, finalization, and error behavior can change without a signature change. Use the exact revision's source, What's New notes, and linked upstream issues to explain each relevant difference.

Follow gh-<number> or issue references in introducing commits to the CPython issue/PR and any linked PEP. ddtrace/internal/datadog/profiling/stack/echion/echion/cpython/tasks.h cites gh-123923 for stack references; a proposal or release-note summary does not replace source verification.

Connect each changed field or API to ddtrace's reads, macros, offsets, copies, and callers. Record the old/new contract, replacement or adaptation, required version guard, and affected files; include caller and upstream source links so the proposed changes can be checked.

Report affected ddtrace callers, the changed contract, required adaptation, and validation across the supported versions/platforms. Treat pre-release behavior as version-specific; do not turn a snapshot into an undated universal rule.