-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
display single contained exception in excgroups in test summary #12975
Conversation
src/_pytest/_code/code.py
Outdated
and isinstance(self.value, BaseExceptionGroup) | ||
and (subexc := _get_single_subexc(self.value)) is not None | ||
): | ||
return f"[in {type(self.value).__name__}] {subexc!r}" |
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.
return f"[in {type(self.value).__name__}] {subexc!r}" | |
return f"{subexc!r} [single exception in {type(self.value).__name__}]" |
as discussed in the issue
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.
fixed, but noted my disagreement in the issue :)
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.
Thanks @jakkdl!
I really appreciate your writeup in #12943 (comment), but continue to prefer this style for a few reasons:
- when the nodeid is long and we can get truncation of this short message, I want to keep the leaf-type as the first part of this message. Generally users who are seeing ExceptionGroups know they're possible, so I'm not too worried about truncating that note away in such cases
- single-leaf groups are qualitatively simpler to think about than multi-leaf groups - the structure of the latter often matters, for example, while the former are basically just extra structure in the traceback - and so discarding the more complex structure feels a bit worse
- I think we'll probably want to do something better for these cases too at some point, but I don't yet know what and would prefer to wait until we have a proposal that users seem enthusiastic about.
I'm happy with this PR as-is since it seems to me like a clear improvement on the status quo; if nobody else has feedback I'll merge in a few days 🙂
fixes #12943
As
ExceptionInfo
still doesn't have proper support for exception groups this continues upon the hacky solution from #10209, modifying the reprcrash as well.I find this solution ... incredibly hacky and ugly, and am not a fan that n==1 gets handled but not n==2. But conceptually it just gets really tricky to figure out what info to strip, and how to show that. If we're going with stripping structure & group messages we could extend this solution to something like
[in ExceptionGroup]: ValueError("foo"), TypeError("bar")
.EDIT: less hacky now that I moved the code to
ExceptionInfo.exconly