[issue25108] traceback.extract_stack() compatibility break in 3.5

Serhiy Storchaka added the comment: Thank you Arfrever. -- ___ Python tracker ___ ___ Python-bugs-list

[issue25108] traceback.extract_stack() compatibility break in 3.5

Roundup Robot added the comment: New changeset 7e718bbf5152 by Serhiy Storchaka in branch '2.7': Issue #25108: Fixed test_traceback in the case when this test is run twice. https://hg.python.org/cpython/rev/7e718bbf5152 -- ___ Python tracker

[issue25108] traceback.extract_stack() compatibility break in 3.5

Arfrever Frehtes Taifersar Arahesis added the comment: > New changeset f6125114b55f by Serhiy Storchaka in branch '2.7': > Issue #25108: Backported tests for traceback functions print_stack(), > https://hg.python.org/cpython/rev/f6125114b55f The new tests fail on 2.7 branch when

[issue25108] traceback.extract_stack() compatibility break in 3.5

Changes by Serhiy Storchaka : -- assignee: -> serhiy.storchaka ___ Python tracker ___

[issue25108] traceback.extract_stack() compatibility break in 3.5

Changes by Serhiy Storchaka : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue25108] traceback.extract_stack() compatibility break in 3.5

Roundup Robot added the comment: New changeset c9fb4362fb9f by Serhiy Storchaka in branch '3.5': Issue #25108: Omitted internal frames in traceback functions print_stack(), https://hg.python.org/cpython/rev/c9fb4362fb9f New changeset 4e617566bcb6 by Serhiy Storchaka in branch 'default': Issue

[issue25108] traceback.extract_stack() compatibility break in 3.5

Serhiy Storchaka added the comment: > wouldn't changing walk_stack to add one more f_back be better? print_stack and format_stack need to add two more f_backs. -- ___ Python tracker

[issue25108] traceback.extract_stack() compatibility break in 3.5

Serhiy Storchaka added the comment: Here is a patch that restores compatibility. There were no tests for print_stack(), format_stack(), and extract_stack() without arguments. New tests are passed with 3.4. There is a difference between this bug and warnings.warn(stacklevel=) at import time.

[issue25108] traceback.extract_stack() compatibility break in 3.5

Nick Coghlan added the comment: Serhiy's explanation and fix look good to me. -- ___ Python tracker ___ ___

[issue25108] traceback.extract_stack() compatibility break in 3.5

Robert Collins added the comment: wouldn't changing walk_stack to add one more f_back be better? Seems odd to work around it... -- ___ Python tracker

[issue25108] traceback.extract_stack() compatibility break in 3.5

New submission from Antoine Pitrou: This can be considered a regression, although perhaps it may not be desirable to fix it in a later release. In 3.4: >>> def f(): return traceback.extract_stack() ... >>> print([x[0:3] for x in f()]) [('', 1, ''), ('', 1, 'f')] In 3.5: >>> print([x[0:3]

[issue25108] traceback.extract_stack() compatibility break in 3.5

Larry Hastings added the comment: Tracebacks aren't my forte, but this does smell like a regression and something that should be fixed. My worry about things like this is that it isn't as much a "bug" as a "badly implemented interface". As in, that's the interface in 3.5, and people will

[issue25108] traceback.extract_stack() compatibility break in 3.5

Robert Collins added the comment: Hmm, I think we can fix this. Its leaking due to the use of a helper I think. So - we should just fix this [and add a test, since clearly the test coverage is insufficient] -- ___ Python tracker

[issue25108] traceback.extract_stack() compatibility break in 3.5

Antoine Pitrou added the comment: Note the doc says "Extract the raw traceback from the current stack frame". The "current stack frame" may be assumed to be the caller's (as it is in previous Python releases). Fortunately, this is also worked around by calling