-
-
Notifications
You must be signed in to change notification settings - Fork 356
More traceback cleaning #3279
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
Comments
Here's something closer to my platonic ideal:
I'm a bit surprised there's nothing pointing to |
Actually part of this is just #2649 I think |
ooh nice. Are there any blockers for #3233? |
Well I missed that you actually approved it! I'll respond to your review. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
https://vorpus.org/blog/beautiful-tracebacks-in-trio-v070/ made tracebacks in some scenarios nicer, but afaict it mostly just affects calls to
trio.run
and when spawning tasks. (Implementation. Tested in test_traceback_frame_removal).But there's still a lot of other scenarios that cause verbose outputs:
I'm not entirely sure what the best approach is to try and clean this up. We could try cleaning up tracebacks in
Cancelled.__init__
, or a custom[Base]ExceptionGroup
that filters the traceback in child exceptions. Other options include modifyingsys.excepthook
, sprinkling tons of__traceback_hide__
, or if there's a few repeat offenders rewriting select code to add fewer frames to the stack.Would also be great to collect more examples of unhelpfully long tracebacks to see if there are repeat offenders that would give disproportionate impact to improve. @Zac-HD
The text was updated successfully, but these errors were encountered: