-
-
Notifications
You must be signed in to change notification settings - Fork 30.9k
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
Possible implementation of negative limit for traceback functions #66809
Comments
This is the possible patch for this proposal: https://mail.python.org/pipermail/python-ideas/2014-October/029826.html. |
def _extract_tb_or_stack_iter(curr, limit, extractor):
# Distinguish frames from tracebacks (need to import types)
if limit is None:
limit = getattr(sys, 'tracebacklimit', None)
elif limit < 0 and isinstance(curr, types.TracebackType):
seq = list(_extract_tb_or_stack_iter(curr, None, extractor))
yield from seq[limit:]
else:
pass |
You forgot a patch. |
Sorry, first time posting here; accidently pressed Enter. |
I have added comments on Retvield (a system for patch reviewing). You should receive an email about this. In general the patch is not optimal. There is no need to load source lines for dropped entries. |
Thanks. I replied to your comments at Retvield. I'll update the patch tomorrow. |
Here's the updated (optimized) patch |
Renamed the cond variable, added tuple unpacking instead of using a single variable. |
I think the reason this patch hasn't been discussed well is that it only changes the behavior for traceback.*_tb functions that only deal with tracebacks. I commented on the review page that we don't have to change the behavior of traceback.*_stack functions to make it obvious. Let me show an example: import sys
def a():
b()
def b():
c()
def c():
d()
def d():
def e():
print_stack(limit=2) # Last 2 entries
''' Output:
File "file", line 331, in d
e()
File "file", line 328, in e
print_stack(limit=2) # Last 2 entries '''
raise Exception
e()
try:
a()
except Exception:
print_exc(limit=2) # 2 entries from the caller
''' Output:
Traceback (most recent call last):
File "file", line 336, in <module>
a()
File "file", line 318, in a
b()
Exception ''' If we decide to unify the behavior of *_tb and *_stack functions, the change will break some existing code, although the breakage will be purely cosmetic. |
More likely the lack of discussion is just that Serhiy is busy :) Breaking code is to be avoided if possible. Can you give an example of the "cosmetic" change? I haven't fully reviewed the patch, but a more meaningful name than 'condition' might make the code more readable. Perhaps 'handling_negative_limit'? |
Last patch is more complicated and needs more time to review. I suppose the code would be more clear if split _extract_tb_or_stack_iter() to parts. One generator just generates (filename, lineno, name, f.f_globals) tuples. Then these tuples either handled directly or passed through a deque with fixed size. And some tests would be good. |
I'm not sure what would be the best way to support negative limit for stack functions. Actually, I think the current behavior is not intuitive. For example we could make positive limit mean the same thing for traceback and stack functions (load N entries, starting from the caller), but in that case the change will inverse the behavior of code that uses stack functions. Since the traceback module is mostly used for printing/formatting the difference won't be crucial. |
I updated the patch. |
Revisiting this issue, I realize that I made quite a few mistakes (because this was the first issue I submitted). The patch is definitely minor, and I'm no longer interested in it. This issue may now be closed. Cheers. |
Moved the latest patch with implementation and tests from bpo-22974 (http://bugs.python.org/issue22974). |
Python Developer's Guide said to ping the issue, in case of one-month long inactivity period. |
I understand that this issue is far from being important, but this is going to be the fourth unreviewed file in this issue. I noted all your comments to me and fixed the patch accordingly, but ever since November I'm the only one who posts something here. I pinged the issue about 4 days ago (after a month of utter silence) and still didn't get any response. Could someone review the latest patch (the one I attach to this message - traceback_rev.diff) or at least say what's wrong with it (or with this issue, or with something else)? |
Some of the patches (including the latest one) were missing Mercurial header. I'm uploading the properly formatted patch (traceback_rev_fixed.diff) |
For future reference, a better initial post would have been more self-contained and explanatory, something like the following. (If I got the proposal wrong, all the more reason to explain it clearly). Do the new tests pass with n=0? If not, do the functions have a sensible behavior (print header and no entries, rather than raising) that could be tested? |
Thank you, Terry. You got the proposal right. I'm glad you noticed the issues with tests, I updated the patch to fix them. |
Hold on, I found 2 more bugs. Will update the patch soon. |
I improved tests for *_stack and *_tb functions, fixed a few typos and added more comments. |
Thank you for your patches Dmitry. But I think that the code can be made simpler. Here is a patch which refactors extracting code. It splits the code on few generators which do different tasks: iterate over tracebacks or frames linked list, limit the size of proceeded sequence, and generates required fields. Note that the behavior of extract_stack() with negative limit differs if sys.tracebacklimit is specified and less than the length of full traceback. Tests are changed too, now they test all combinations of the limit parameter and sys.tracebacklimit. |
Ping |
Again, I'm honestly sorry if I'm being annoying, but is there anything else that needs to be done in order to make this issue "resolved"? The stage is set to "patch review", although there were no messages posted since the latest patch was submitted and there're no comments to the Patch set 6 in Rietveld.
Is this true for the "patch review" stage? I pinged this issue about a month ago, but haven't got any response; should I have emailed python-dev@python.org even if the patch is not mine? |
I proposed changed patch. It needs a review. |
Needed a documentation. I'm not interested in writing it. |
I'll do that tomorrow. The patch still needs a review though... |
Here's the documentation patch. |
As francismb noted, there are too long lines in the patch. They should be wrapped. |
Thanks, completely missed the abs(limit) part. Here's the updated documentation patch. |
Nice, looks pretty elegant to me. I have nothing to add to the prior reviewers comments. |
New changeset eb6052605fd8 by Serhiy Storchaka in branch 'default': |
Thank you for your contribution Dmitry. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: