GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | ||||||||||||||||||||||||||||||||||||||||||||||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | ||||||||||||||||||||||||||||||||||||||||||||||||
GeezerVison is showing github.com — gh-99553: add tests for ExceptionGroup wrapping by Zac-HD · Pull Request #99615 · python/cpython Conversation
|
|
@Zac-HD I cannot do that, but if you change you PR title from |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
Co-authored-by: Shantanu <[email protected]>
| A subclass of :exc:`BaseExceptionGroup` that extends :exc:`Exception` | ||
| cannot wrap :exc:`BaseException`\ s, as is the case with :exc:`ExceptionGroup`. | ||
| However, there is no further restriction: a :exc:`BaseExceptionGroup` subclass | ||
| which extends :exc:`KeyError` could wrap any :exc:`Exception`. |
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
I think this is a strange thing to say in a doc, because why would you expect it to not wrap any Exception?
Maybe instead of the second sentence we could just explain the motivation for the restriction: “This ensures that wrapped BaseExceptions are not caught by ‘except Exception’.”
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
why would you expect it to not wrap any Exception?
Suppose we have class MyEG(BaseExceptionGroup, X):, where except X: will catch such a group because it extends X. We disallow wrapping BaseExceptions in an ExceptionGroup because they would not be caught by except Exception: if unwrapped.
However this logic is not applied consistently: if X is e.g. KeyError, then except KeyError: can indeed catch MyEG("", [ValueError()]). I find this inconsistency surprising, which is why I commented on #99572 and then opened this PR!
(I'm not trying to reopen the design discussion, just trying to explain my perspective)
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Ok, I see. Well yes, the Exception case is different - people use ‘expect Exception’ as ‘catch everything except fatal errors’.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
Co-authored-by: Shantanu <[email protected]>
|
Ready to merge, I think? |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
| A subclass of :exc:`BaseExceptionGroup` that extends :exc:`Exception` | ||
| cannot wrap :exc:`BaseException`\ s, as is the case with :exc:`ExceptionGroup`. | ||
| However, there is no further restriction: a :exc:`BaseExceptionGroup` subclass | ||
| which extends :exc:`KeyError` could wrap any :exc:`Exception`. |
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
I don't think this comment is easy to understand without the justification. How about this?
| A subclass of :exc:`BaseExceptionGroup` that extends :exc:`Exception` | |
| cannot wrap :exc:`BaseException`\ s, as is the case with :exc:`ExceptionGroup`. | |
| However, there is no further restriction: a :exc:`BaseExceptionGroup` subclass | |
| which extends :exc:`KeyError` could wrap any :exc:`Exception`. | |
| Like :exc:`ExceptionGroup`, user-defined subclasses of :exc:`BaseExceptionGroup` | |
| that extend :exc:`Exception` can only wrap :exc:`Exception` subclasses. | |
| This is to prevent exceptions that represent fatal errors from being wrapped in an | |
| exception group which can be caught by ``except Exception``. See also :ref:`exceptions`. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Please address Irit's review.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated. Once you have made the requested changes, please leave a comment on this pull request containing the phrase |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
I've taken a few attempts, and haven't found a way to explain this which reliably clarifies rather than confuses, so I'll just close the PR 🙂 |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
|
If it's hard to figure out appropriate changes to the docs, I can at least merge the tests. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
Thanks @Zac-HD for the PR, and @hauntsaninja for merging it 🌮🎉.. I'm working now to backport this PR to: 3.11. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
(cherry picked from commit 4cd1cc8) Co-authored-by: Zac Hatfield-Dodds <[email protected]>
|
GH-103435 is a backport of this pull request to the 3.11 branch. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
Thank you! |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
(cherry picked from commit 4cd1cc8) Co-authored-by: Zac Hatfield-Dodds <[email protected]>
There was an error while loading. Please reload this page.
Successfully merging this pull request may close these issues.
There was an error while loading. Please reload this page.