| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| Expand Up | @@ -655,6 +655,12 @@ and information about handling exceptions is in section :ref:`try`. | |
| The ``__suppress_context__`` attribute to suppress automatic display of the | ||
| exception context. | ||
|
|
||
| .. versionchanged:: 3.11 | ||
| If the traceback of the active exception is modified in an :keyword:`except` | ||
| clause, a subsequent ``raise`` statement re-raises the exception with the | ||
| modified traceback. Previously, the exception was re-raised with the | ||
| traceback it had when it was caught. | ||
|
Comment thread
Comment on lines
+661
to
+662
Copy link
Copy Markdown
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality
Isn't this a bug and that particular change should therefore be backported? I recently got surprised by this behavior of raise when using BaseException.with_traceback in Python 3.10: I was able to set e.__traceback__ to a custom traceback with e.with_traceback(my_custom_tb), even verified with e.__traceback__ == my_custom_tb, yet a bare raise raised the exception like no changes had been made. (Also adding to this confusion: Changes to the original traceback like e.__traceback__.tb_next = None did successfully show up with bare raise.)
Sorry, something went wrong.
All reactions
Copy link
Copy Markdown
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low QualitySo I originally wanted to post this as an issue but discovered that the behavior seemingly disappeared when using Python 3.11. With some help I found out about this PR where one of the changes fixes the behavior of bare raise. So I thought it would be the best idea to ask here via comment since @iritkatriel is also listed as the maintainer for the traceback module anyway? I hope that's okay.
Sorry, something went wrong.
All reactions
Copy link
Copy Markdown
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low QualityHere's a short example to explain what I mean: Python 3.10.11 (main, May 4 2023, 06:08:16) [GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> def f(): g()
...
>>> def g(): h()
...
>>> def h(): raise Exception
...
>>> # Trying to show only the "most recent" step of the traceback; doesn't work:
>>> try:
... f()
... except Exception as e:
... tb = e.__traceback__
... while tb.tb_next is not None:
... tb = tb.tb_next
... e.with_traceback(tb)
... raise
...
Exception()
Traceback (most recent call last):
File "<stdin>", line 2, in <module>
File "<stdin>", line 1, in f
File "<stdin>", line 1, in g
File "<stdin>", line 1, in h
Exception
>>> # However, modifying the traceback is possible in general. For example,
>>> # reducing the traceback to the "earliest" step of the original traceback:
>>> try:
... f()
... except Exception as e:
... e.__traceback__.tb_next = None
... raise
...
Traceback (most recent call last):
File "<stdin>", line 2, in <module>
Exception
>>>
Sorry, something went wrong.
All reactions
Copy link
Copy Markdown
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low QualityWe can't backport this change, it's way too invasive for that. This behaviour existed since 3.0, unfortunately.
Sorry, something went wrong.
All reactions
Copy link
Copy Markdown
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low QualityIf you "raise e" instead of "raise" then you will see the edited traceback (but with the current frame added).
Sorry, something went wrong.
All reactions
|
||
|
|
||
| .. _break: | ||
|
|
||
| The :keyword:`!break` statement | ||
| Expand Down | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| Expand Up | @@ -181,6 +181,12 @@ Other CPython Implementation Changes | |
| hash-based pyc files now use ``siphash13``, too. | ||
| (Contributed by Inada Naoki in :issue:`29410`.) | ||
|
|
||
| * When an active exception is re-raised by a :keyword:`raise` statement with no parameters, | ||
| the traceback attached to this exception is now always ``sys.exc_info()[1].__traceback__``. | ||
|
Comment thread
Copy link
Copy Markdown
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low QualityThe use of sys.exc_info()[1] always puts me off -- it's just too cryptic. Maybe "the traceback attached to this exception is now always its __traceback__ attribute? Or use the phrasing from the reference manual above?
Sorry, something went wrong.
All reactions
|
||
| This means that changes made to the traceback in the current :keyword:`except` clause are | ||
| reflected in the re-raised exception. | ||
| (Contributed by Irit Katriel in :issue:`45711`.) | ||
|
|
||
| New Modules | ||
| =========== | ||
|
|
||
| Expand Down Expand Up | @@ -266,6 +272,16 @@ sqlite3 | |
| (Contributed by Erlend E. Aasland in :issue:`45828`.) | ||
|
|
||
|
|
||
| sys | ||
| --- | ||
|
|
||
| * :func:`sys.exc_info` now derives the ``type`` and ``traceback`` fields | ||
| from the ``value`` (the exception instance), so when an exception is | ||
| modified while it is being handled, the changes are reflected in | ||
| the results of subsequent calls to :func:`exc_info`. | ||
| (Contributed by Irit Katriel in :issue:`45711`.) | ||
|
|
||
|
|
||
| threading | ||
| --------- | ||
|
|
||
| Expand Down Expand Up | @@ -579,6 +595,17 @@ New Features | |
| suspend and resume tracing and profiling. | ||
| (Contributed by Victor Stinner in :issue:`43760`.) | ||
|
|
||
| * :c:func:`PyErr_SetExcInfo()` no longer uses the ``type`` and ``traceback`` | ||
| arguments, the interpreter now derives those values from the exception | ||
| instance (the ``value`` argument). The function still steals references | ||
| of all three arguments. | ||
| (Contributed by Irit Katriel in :issue:`45711`.) | ||
|
|
||
| * :c:func:`PyErr_GetExcInfo()` now derives the ``type`` and ``traceback`` | ||
| fields of the result from the exception instance (the ``value`` field). | ||
| (Contributed by Irit Katriel in :issue:`45711`.) | ||
|
|
||
|
|
||
| Porting to Python 3.11 | ||
| ---------------------- | ||
|
|
||
| Expand Down | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,6 @@ | ||
| The three values of ``exc_info`` are now always consistent with each other. | ||
| In particular, the ``type`` and ``traceback`` fields are now derived from | ||
| the exception instance. This impacts the return values of :func:`sys.exc_info` | ||
| and :c:func:`PyErr_GetExcInfo()` if the exception instance is modified while | ||
| the exception is handled, as well as :c:func:`PyErr_SetExcInfo()`, which now | ||
| ignores the ``type`` and ``traceback`` arguments provided to it. |
| Back | FazBrowse Home | New Git URL |
Uh oh!
There was an error while loading. Please reload this page.