]> git.ipfire.org Git - thirdparty/Python/cpython.git/commit
gh-96092: Fix traceback.walk_stack(None) skipping too many frames (#129330)
authorAmmar Askar <ammar@ammaraskar.com>
Thu, 13 Feb 2025 01:43:09 +0000 (20:43 -0500)
committerGitHub <noreply@github.com>
Thu, 13 Feb 2025 01:43:09 +0000 (01:43 +0000)
commitf9a7d41bacb78b9d6e095be049befdec19ffda0a
treeba14fa66f7e6bb0806dcec4ed95ff9bb7aa8fe1d
parent6fb5138776fe84e3769b8aff66c1726c788d84ed
gh-96092: Fix traceback.walk_stack(None) skipping too many frames (#129330)

As it says in its documentation, walk_stack was meant to just
follow `f.f_back` like other functions in the traceback module.
Instead it was previously doing `f.f_back.f_back` and then this
changed to `f_back.f_back.f_back.f_back' in Python 3.11 breaking
its behavior for external users.

This happened because the walk_stack function never really had
any good direct tests and its only consumer in the traceback module was
`extract_stack` which passed the result into `StackSummary.extract`.
As a generator, it was previously capturing the state of the stack
when it was first iterated over, rather than the stack when `walk_stack`
was called. Meaning when called inside the two method deep
`extract` and `extract_stack` calls, two `f_back`s were needed.
When 3.11 modified the sequence of calls in `extract`, two more
`f_back`s were needed to make the tests happy.

This changes the generator to capture the stack when `walk_stack` is
called, rather than when it is first iterated over. Since this is
technically a breaking change in behavior, there is a versionchanged
to the documentation. In practice, this is unlikely to break anyone,
you would have been needing to store the result of `walk_stack` and
expecting it to change.
Doc/library/traceback.rst
Lib/test/test_traceback.py
Lib/traceback.py
Misc/NEWS.d/next/Library/2025-01-26-19-35-06.gh-issue-96092.mMg3gL.rst [new file with mode: 0644]