-
-
Notifications
You must be signed in to change notification settings - Fork 32.2k
gh-120521: clarify except* documentation to allow tuples #120523
New issue
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
Conversation
Doc/reference/compound_stmts.rst
Outdated
@@ -378,8 +378,8 @@ exception group with an empty message string. :: | |||
... | |||
ExceptionGroup('', (BlockingIOError())) | |||
|
|||
An :keyword:`!except*` clause must have a matching type, | |||
and this type cannot be a subclass of :exc:`BaseExceptionGroup`. | |||
An :keyword:`!except*` clause must have a matching type or a tuple of matching |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be worth expanding this further:
- The docs for
except
(the previous section) never say that each type must be a subtype ofBaseException
. That's probably worth adding. - One important difference between
except
andexcept*
is that the former allows "bare" except clauses (justexcept:
), butexcept*
doesn't. I think that's worth mentioning in a sentence by itself. - We don't say what happens if the type is a subclass of BaseExceptionGroup.
So I'd suggest something like this:
An :keyword:`!except*` clause must have a matching type or a tuple of matching | |
Unlike :keyword:`except` clauses, :keyword:`!except*` clauses must have a matching | |
expression; `except*:` is not valid syntax. When the handler is evaluated, the | |
expression must evaluate to a type or a tuple containing types. Each type must be a | |
subclass of :exc:`BaseException` and must not be a subclass of :exc:`BaseExceptionGroup`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, I've added a mention that the runtime will raise a TypeError if the type is wrong, and updated the except
section to have similar language.
Should the latter be split into a separate PR, or should I just update the title/summary of this PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks right, cc @iritkatriel for except*
.
Co-authored-by: Jelle Zijlstra <[email protected]>
Co-authored-by: Jelle Zijlstra <[email protected]>
Co-authored-by: Irit Katriel <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice explanation!
I think this PR should just resolve the issue it is associated with. As it is now it is doing a lot more than that. Can you limit the PR to just resolve the problem raised in the issue? |
I'll remove the Do you have a preference for how to split it up? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it became a bit wordy. I tried to reword it more concisely.
Doc/reference/compound_stmts.rst
Outdated
matching expression; ``except*:`` is not valid syntax. In addition to the | ||
requirements for matching expressions in :keyword:`except` clauses, the | ||
types in the matching expression of an :keyword:`!except*` clause cannot | ||
be :exc:`BaseExceptionGroup` or a subclass of :exc:`BaseExceptionGroup`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Above we talk about "exception group" when we refer to BaseException and its subclasses).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I'm confused about this comment - is it addressed in your suggestions already?
The other suggestions on this PR which I've merged in seem to have removed all references to BaseException and BaseExceptionGroup classnames in this doc.
Feels like explicitly mentioning the class names would be more clear, wouldn't it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this comment is addressed.
Since we talk about "exception group" in the previous paragraphs, assuming the reader knows what we mean there, I don't think specifying the type here would add clarity.
Co-authored-by: Irit Katriel <[email protected]>
Co-authored-by: Irit Katriel <[email protected]>
Co-authored-by: Irit Katriel <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, I'll let @JelleZijlstra have another look.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, just a wording suggestion
For an :keyword:`!except` clause with an expression, the | ||
expression must evaluate to an exception type or a tuple of exception types. | ||
The raised exception matches an :keyword:`!except` clause whose expression evaluates | ||
to the class or a :term:`non-virtual base class <abstract base class>` of the exception object, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a pre-existing problem and doesn't have to be solved in this PR, but I don't think linking to the definition of "abstract base class" here is great.
Co-authored-by: Jelle Zijlstra <[email protected]>
Thanks @yangdanny97 for the PR, and @JelleZijlstra for merging it 🌮🎉.. I'm working now to backport this PR to: 3.12, 3.13. |
…nGH-120523) (cherry picked from commit 58b3f11) Co-authored-by: Danny Yang <[email protected]> Co-authored-by: Jelle Zijlstra <[email protected]> Co-authored-by: Irit Katriel <[email protected]>
GH-120750 is a backport of this pull request to the 3.13 branch. |
…nGH-120523) (cherry picked from commit 58b3f11) Co-authored-by: Danny Yang <[email protected]> Co-authored-by: Jelle Zijlstra <[email protected]> Co-authored-by: Irit Katriel <[email protected]>
GH-120751 is a backport of this pull request to the 3.12 branch. |
…20523) (#120751) (cherry picked from commit 58b3f11) Co-authored-by: Danny Yang <[email protected]> Co-authored-by: Jelle Zijlstra <[email protected]> Co-authored-by: Irit Katriel <[email protected]>
…20523) (#120750) (cherry picked from commit 58b3f11) Co-authored-by: Danny Yang <[email protected]> Co-authored-by: Jelle Zijlstra <[email protected]> Co-authored-by: Irit Katriel <[email protected]>
…n#120523) Co-authored-by: Jelle Zijlstra <[email protected]> Co-authored-by: Irit Katriel <[email protected]>
…n#120523) Co-authored-by: Jelle Zijlstra <[email protected]> Co-authored-by: Irit Katriel <[email protected]>
…n#120523) Co-authored-by: Jelle Zijlstra <[email protected]> Co-authored-by: Irit Katriel <[email protected]>
fixes #120521
Discussion link: https://discuss.python.org/t/clarifying-typing-behavior-for-exception-handlers-except-except/55060/2
📚 Documentation preview 📚: https://cpython-previews--120523.org.readthedocs.build/