-
-
Notifications
You must be signed in to change notification settings - Fork 32k
Add limit_group
option to traceback.format_exception_only
#111448
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
|
Yes :) |
Well, if format_exception_only should respect them then it should give them the same names. But it's not the intention that the convenience wrappers will support everything that TracebackException supports. The wrappers should do something reasonable, and users who need to fine control over the traceback should use TracebackException directly. |
Sorry, I am a bit confused about which names you are talking about. Maybe we should move this discussion to the PR? So we can have the same context. |
My point is that we don't need to complicate the API with another parameter (limit_group). Just make format_exception_only respect the existing limits on groups, and if anyone wants to turn that off they can do it by controlling those args. |
Oh, I see 👍 |
Feature or enhancement
Right now there's no limit in both width and depth that
format_exception_only
prints exception groups.I propose adding
limit_group=True
parameter that will respectmax_group_depth
andmax_group_width
values and add... (max_group_depth is {self.max_group_depth})\n
andand {remaining} more exception{plural}\n
, just like.format()
does.There are two reasons why I propose adding this option.
The first reason is that it will be consistent with
.format()
. One of the use-cases forformat_exception_only
is to compare parsed traceback produced by.format()
with the one returned fromformat_exception_only
. Right now (in my patch) it fails to compare these two corner-cases: too deep group and too wide group.The second reason is that this code simply fails:
This is not very realistic, but it is totally possible.
This option will prevent this case from happening.
Questions:
limit_group
, because it is in sync withshow_group
True
, because it is safer (RecursionError
case won't happen)I have a PR ready :)
This is a part of #104150
Linked PRs
traceback.format_exception_only
respectmax_group_width
andmax_group_depth
#111952The text was updated successfully, but these errors were encountered: