Skip to content
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

Suggestion: use stack_data for better tracebacks #145

Closed
alexmojaki opened this issue Jul 7, 2020 · 2 comments
Closed

Suggestion: use stack_data for better tracebacks #145

alexmojaki opened this issue Jul 7, 2020 · 2 comments
Labels
enhancement New feature or request

Comments

@alexmojaki
Copy link

Hi! I've recently created a few libraries that are helpful for extracting information from frames and tracebacks, and I think they could be very useful to rich.

  • executing can identify the exact AST node being executed by a frame in many cases. It's always disappointed me that Python only points to a line in each frame in tracebacks, especially when the expression/statement at fault spans many lines. Sometimes it can be really hard to interpret. Currently executing is used in IPython (in master, unreleased) to highlight the node, here's what it looks like:

ipython

  • executing can also infer a function __qualname__ from a code object, meaning your traceback can say lorem/ipsum.py in MyClass.__init__ at line 123 instead of just __init__, which is much more informative.
  • pure_eval can safely evaluate certain AST nodes without side effects, so that if the source for a frame contains expressions like self.foo and bar[key] their values can often be shown alongside plain variables.
  • stack_data collects data from tracebacks for the purpose of formatting and displaying them. It uses executing and pure_eval and also provides a lot of functionality of its own. I integratedstack_data into IPython which allowed removing a lot of flaky custom introspection code, fixing several bugs and making the code more maintainable.

For rich, I'm thinking you could use stack_data to:

  • Reduce the amount of code in the repo.
  • More intelligently select which lines of code to display, instead of just a fixed number lines before and after.
  • Display the values of local variables and other expressions for each frame in a nice table.
  • Highlight the node being executed.
  • Show the code qualname.
  • Handle repeated frames, especially when the user gets a RecursionError: maximum recursion depth exceeded. Right now it gets stuck for a while before producing a massive traceback.

What do you think? If you want to know more I suggest looking through the stack_data README to get an idea of what it can do and how to use it.

@willmcgugan
Copy link
Collaborator

Hi @alexmojaki

That does look like it would make a very nice addition to Rich tracebacks. Thanks for letting me know, I'm going to go through your work and see what I can make use of.

@willmcgugan
Copy link
Collaborator

Closing this to tidy issues, but keeping a note of it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants