Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Support strict_exception_groups=True #188
Support strict_exception_groups=True #188
Changes from 9 commits
8f04a5c
7eb779b
c3f7dc2
8fd6db1
69853c3
f22fa75
4e6f1c7
5560766
a9f14a1
40369d0
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Hi John-- I may be slow in reviewing.
Please make sure the PR description summarizes the changes (e.g. mentions the internal error, API policy about exception groups, etc.).
Would need test coverage for any changes, but ok to hold off until I've reviewed the basics (as I can't promise we'll take the direction of this PR).
Please see #177. On type checking, I'm ok running a loose mypy pass, but reluctant to convert the codebase to strict type annotations, since fighting the type system is often a burden on maintenance (especially with a project on life support).
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.
Ah thank you, of course I'd complained about lack of Black before 😅
Agree on loose mypy just to check if the annotations that exist are correct. And I don't have any plans on adding annotations everywhere, just doing it for my own sake when developing.
Will try and make PR summary verbose and descriptive 👍
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.
In principle I'd like to state that the API doesn't raise exception groups, and that would include the server API. For the user's handler, perhaps add
UserRequestHandlerException
?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 that for users that are embracing
strict_exception_groups=True
and are used to handling exceptiongroups everywhere we shouldn't purposely obscure the groups and make errors harder for them to handle (and Trio's stance is that this is the default and should be embraced). I haven't delved too too deeply into them to see what it would imply to try and avoid exceptiongroups, but I think it might necessitate a change in API where we might end up changing what exceptions are being raised - even for users sticking withstrict_exception_groups=False
.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.
Multiple Cancelled was an existing possible case, so do we need to try hard to make it a single exception? (Cancelled is typically caught by trio itself, and otherwise the user had to deal with MultiError Cancelled anyway.)
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.
The problem is that it's a very easy gotcha to write
which might work 99% of the time, but then at some random point you get multiple instead of a single (or the other way around)
Cancelled
, and your exception handler is now broken. I agree thatCancelled
is perhaps a special case due to trio handling it, but if it does surface to the user I'm not sure there's much to be gained from having them see multiple of them.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.
MultiError with Cancelled can happen fairly easily, and we quickly learned never to write
except Cancelled
in our application.By this trio-websocket change, we're masking the user from the effects of a trio anti-pattern, which is concerning. For example, the user may get away with
except Cancelled
when the trio-websocket API is involved, but then be doubly puzzled when it doesn't work with another API.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.
Hrm, I think this would be a very bad design choice. With this PR we're trying to make the internal nursery an implementation detail, as per https://trio.readthedocs.io/en/stable/reference-core.html#designing-for-multiple-errors
Before
strict_exception_groups=True
was the default it was expected that a trio developer would be able to handle the occasionalMultiError
, but sincestrict=True
trio is trying very hard to make it fully consistent - either you always get anExceptionGroup
, or you never get one. And all other library APIs are encouraged to follow in those footsteps.In the future the users shouldn't need to worry about this anti-pattern at all, so I do not think we should enshrine it in this API.
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 forgot if we discussed already, but I think
Optional[Foo]
is more friendly / readable thanFoo | None
.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
|None
is the standard way of doing it nowadays, and pyupgrade/ruff will warn on doingOptional[...]
: https://docs.astral.sh/ruff/rules/non-pep604-annotation/I also think it's nice for newbies not to have another keyword to know, and highly personally I prefer not having to do another import for it.