Traceback extra_lines for just last entry

[ewels]

I love the traceback rendering in Rich, and I love the extra_lines argument, which gives more context around the code causing problems. However, adding these extra lines around each entry in the traceback can make it super long - for example, I've started noticing that people can't post them in Slack because they exceed the maximum message length. The traceback length can actually make it harder to read as the log messages are now so far above it that you have to scroll for miles.

Most of the time, it's only really the final entry which is of real interest to me. I would love it if I could tell Rich to have extra_lines=3 on just that final entry in the stack but have extra_lines=0 on everything else.

Is this already possible somehow? Would it be a valid feature request for Rich?

Phil

[willmcgugan]

That's certainly possible. I could add an extra_lines_last argument. But in my experience the most relevant frame isn't always the very last one.

I was wondering if it would be worthwhile adding a smarter mechanism to decide which frames to emphasize and which to reduce. Like demoting stdlib frames and code in site packages, and emphasizing your own project. Or maybe it could be as simple as emphasizing the last n frames.

Not sure what the best approach would be to satisfy everyone's use case. Would be great to get more feedback on this one.

[ewels]

Ah that's a great idea! How about something as simple as extra_lines_module={'my_module':3}? Combined with extra_lines=0 to make everything else minimal. Auto-detecting would also be nice of course 👍🏻

[willmcgugan]

Yeah, I like that idea. Could also do the same for locals, which can be too verbose for the entire traceback.

[ewels]

While we're on the topic of compressing the length of the tracebacks, would it be possible to customise the number of newlines in the traceback too? When using extra_lines=0 the whitespace starts taking up quite a lot of space. Could be something like whitespace_before and whitespace_after?

eg. instead of this:

╭───────────────────────────────────── Traceback (most recent call last) ──────────────────────────────────────╮
│ /Users/demo/miniconda3/envs/py3/bin/demo:33 in <module>                                                      │
│                                                                                                              │
│ ❱ 33 │   sys.exit(load_entry_point('demo', 'console_scripts', 'demo')())                                     │
│                                                                                                              │
│ /example/demo/__main__.py:57 in run_demo                                                                     │
│                                                                                                              │
│ ❱  57 │   demo_cli()                                                                                         │
│                                                                                                              │
│ /Users/demo/miniconda3/envs/py3/lib/python3.7/site-packages/click/core.py:829 in __call__                    │
│                                                                                                              │
│ ❱  829 │   │   return self.main(*args, **kwargs)                                                             │
│                                                                                                              │
│ /Users/demo/miniconda3/envs/py3/lib/python3.7/site-packages/click/core.py:782 in main                        │
│                                                                                                              │
│ ❱  782 │   │   │   │   │   rv = self.invoke(ctx)                                                             │
│                                                                                                              │
│ /Users/demo/miniconda3/envs/py3/lib/python3.7/site-packages/click/core.py:1259 in invoke                     │
│                                                                                                              │
│ ❱ 1259 │   │   │   │   │   return _process_result(sub_ctx.command.invoke(sub_ctx))                           │

Be able to have this:

╭───────────────────────────────────── Traceback (most recent call last) ──────────────────────────────────────╮
│ /Users/demo/miniconda3/envs/py3/bin/demo:33 in <module>                                                      │
│ ❱ 33 │   sys.exit(load_entry_point('demo', 'console_scripts', 'demo')())                                     │
│ /example/demo/__main__.py:57 in run_demo                                                                     │
│ ❱  57 │   demo_cli()                                                                                         │
│ /Users/demo/miniconda3/envs/py3/lib/python3.7/site-packages/click/core.py:829 in __call__                    │
│ ❱  829 │   │   return self.main(*args, **kwargs)                                                             │
│ /Users/demo/miniconda3/envs/py3/lib/python3.7/site-packages/click/core.py:782 in main                        │
│ ❱  782 │   │   │   │   │   rv = self.invoke(ctx)                                                             │
│ /Users/demo/miniconda3/envs/py3/lib/python3.7/site-packages/click/core.py:1259 in invoke                     │
│ ❱ 1259 │   │   │   │   │   return _process_result(sub_ctx.command.invoke(sub_ctx))                           │

or even this..?

╭───────────────────────────────────── Traceback (most recent call last) ──────────────────────────────────────╮
│ /Users/demo/miniconda3/envs/py3/bin/demo:33 in <module>                                                      │
│ ❱ 33 │   sys.exit(load_entry_point('demo', 'console_scripts', 'demo')())                                     │
│                                                                                                              │
│ /example/demo/__main__.py:57 in run_demo                                                                     │
│ ❱  57 │   demo_cli()                                                                                         │
│                                                                                                              │
│ /Users/demo/miniconda3/envs/py3/lib/python3.7/site-packages/click/core.py:829 in __call__                    │
│ ❱  829 │   │   return self.main(*args, **kwargs)                                                             │
│                                                                                                              │
│ /Users/demo/miniconda3/envs/py3/lib/python3.7/site-packages/click/core.py:782 in main                        │
│ ❱  782 │   │   │   │   │   rv = self.invoke(ctx)                                                             │
│                                                                                                              │
│ /Users/demo/miniconda3/envs/py3/lib/python3.7/site-packages/click/core.py:1259 in invoke                     │
│ ❱ 1259 │   │   │   │   │   return _process_result(sub_ctx.command.invoke(sub_ctx))                           │

[willmcgugan]

Potentially... But the whitespace really aids legibility, IMHO. I find the first traceback is more readable than the following 2.

Obviously I'd like to cover everybody's requirements, and too-long tracebacks are a legit concern, but exposing too many variables can lead to an overly complicated interface. I'll play around with it at some point and see if there is a compromise...

[ewels]

Yup, I agree that at some point I should stop asking for arguments and just start overwriting some classes 😅

I think the third example is my favourite here as each line / code block is clearly associated to its source. With equal spacing above and below (especially with 1 line tracebacks) I feel that they get a bit lost.

For context, in this case I'm using tracebacks and asking users to post them in bug reports. So the person seeing / copying them won't benefit from context, but will benefit from it being easier to copy. Bit of an edge case scenario though and default tracebacks work fine for me, just prefer using rich throughout where possible!

[ewels]

For any future googlers, I ended up doing a bit of a hybrid monster to get my compact traceback in the end - using traceback.format_exc() to get the short exception info and then using Rich to format that nicely with Python syntax highlighting.

Commit here: MultiQC/MultiQC@3451833

Looks like this:

This was a bit of a niche use case as the person reading the traceback wasn't going to be the one using it. So ease of copying into a GitHub issue was the # 1 priority. I'd still be interested in the other options discussed above for different tools 👍🏻