-
Notifications
You must be signed in to change notification settings - Fork 322
Replace deprecated use of MultiError with exceptiongroup #679
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
Replace deprecated use of MultiError with exceptiongroup #679
Conversation
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.
Small changes needed and LGTM
@@ -142,8 +143,7 @@ def run(self) -> None: | |||
|
|||
emulate_idle_callbacks = _TrioIdleCallbackInstrument(self._idle_callbacks) | |||
|
|||
# TODO(Aleksei): trio.MultiError is deprecated in favor of exceptiongroup package usage and `Except *` | |||
with trio.MultiError.catch(self._handle_main_loop_exception): | |||
with exceptiongroup.catch({BaseException: self._handle_main_loop_exception}): |
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 change needs lower constraints for trio
version
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.
Oops, good point.
Do you mean just adding a constraint on the dependency, or do you want it to work on old versions of trio?
I can implement a shim so that this uses exceptiongroup.catch on new versions of trio and MultiError.catch on older ones if you want. It's not super hard, but does open up the annoying question of how to test on multiple versions of trio.
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.
Personally I prefer constraints on requirements, because support of unlimited legacy versions is an unlimited pain.
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.
Yup, I think this makes more sense too. I just wasn't sure what your preferences were. I've now pushed a version with a constraint on the earliest version of trio where this should work.
@@ -47,7 +47,7 @@ classifiers = {file = ["classifiers.txt"]} | |||
[project.optional-dependencies] | |||
glib = ["PyGObject"] | |||
tornado = ["tornado"] | |||
trio = ["trio"] | |||
trio = ["trio>=0.22.0", "exceptiongroup"] |
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.
Please also add exceptiongroup
to the functional tests requirements. Without it tests fail
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.
Whoops, sorry. I'd only run the tests on Python 3.10 so hadn't noticed that they failed on later Python versions. Now pushed a fix.
Pull Request Test Coverage Report for Build 6996535478
💛 - Coveralls |
Checklist
master
orpython-dual-support
branchtox
successfully in local environmentDescription:
This pull request fixes a deprecation warning when running with recent versions of trio (and a TODO comment from the relevant section of the code) by replacing usage of trio's
MultiError.catch
withexceptiongroup.catch
. It required a little bit of fiddling to get the right semantics, but as far as I can tell this should now be identical behaviour without the deprecation warning (and it passes all the tests)This does have the possibly slightly undesirable feature of adding a dependency on exceptiongroup for using trio. I think this is mostly harmless - it's a dependency of trio anyway in Python versions prior to
except*
syntax being added. If you want I can do a slightly more complicated version of this pull request that removes the dependency on Python versions recent enough to not need it, but that seemed likely to be more trouble than it was worth compared to just installing the backport unconditionally.