-
Notifications
You must be signed in to change notification settings - Fork 6
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
Change defer_to_* to be based on [Base]ExceptionGroup #23
Conversation
Codecov ReportAttention:
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## master #23 +/- ##
===========================================
- Coverage 100.00% 99.35% -0.65%
===========================================
Files 15 15
Lines 454 468 +14
===========================================
+ Hits 454 465 +11
- Misses 0 3 +3 ☔ View full report in Codecov by Sentry. |
@@ -36,7 +36,8 @@ | |||
package_dir={'': 'src'}, | |||
install_requires=[ | |||
'async_generator', | |||
'trio >= 0.11.0' | |||
'trio >= 0.11.0', |
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.
Note that trio-util supports old, pre-ExceptionGroup versions of trio. As the primary user of trio-util, my own organization is still on trio 0.21. Effectively, this PR is disallowing trio < 0.22.
def multi_error_defer_to( | ||
*privileged_types: Type[BaseException], | ||
propagate_multi_error: bool = True, | ||
strict: bool = True, | ||
) -> ContextManager[None]: | ||
"""Deprecated alias for exceptgroup_defer_to().""" | ||
import warnings | ||
warnings.warn( |
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 renaming and warning probably isn't worth it (I suspect my org is the only one using these functions).
I'm not sure it even makes sense to carry these exception utilities into the future. They were introduced as a way to make a pre-ExceptionGroup world more manageable.
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 didn't consider this only really being for pre-ExceptionGroup code. Might just close this then, if they should be effectively deprecated?
I should refine my statement: they were introduced as a way to make lack of except*
syntax more manageable. Without the syntax, it's a burden for API users to deal with "exception Foo or Foo wrapped inside an exception group". The filtering utils of MultiError and the exceptiongroup shim don't help with it.
Since projects don't always have freedom to use the newest python versions, these utilities still have a place. But it's still probably the case that no one is using them or will miss them.
I didn't consider this only really being for pre- |
Trio will be removing MultiError in favour of using ExceptionGroup (via backport on <3.11). This renames
multi_error_defer_to
→except_group_defer_to
and changes the logic to detectBaseExceptionGroup
instead ofMultiError
. SinceMultiError
is a subclass, this should still work with existing code. The old name has an alias that warns when used.While I was editing the module, I also fully type hinted it.