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

stack_data, executing, and pure_eval #252

Open
alexmojaki opened this issue Jan 1, 2021 · 5 comments
Open

stack_data, executing, and pure_eval #252

alexmojaki opened this issue Jan 1, 2021 · 5 comments
Labels
awaiting feedback Awaiting a response from a customer. Will be automatically closed after approximately 2 weeks. needs discussion Requires internal analysis/discussion

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 bugsnag.

  • 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.
  • stack_data identifies the locations of variables and evaluated expressions in the source lines. An intelligent UI could use this, for example, to allow the user to hover over a variable in source code to see its value rather than scroll through a list to find it.

I'll be honest, I've never used bugsnag before (in fact I only just learned about it) so I don't know exactly what would make sense. But I made a similar issue on sentry (getsentry/sentry-python#748) and integrated a couple of these features in there and they seemed pretty happy, particularly with pure_eval. Seeing as you guys are an alternative to sentry, I thought it made sense to give you a heads up. I don't actually have time to integrate these myself, but I'd be happy to help with any questions you have.

@mattdyoung
Copy link

Hey @alexmojaki

Thanks for highlighting these libraries to us! We plan to take a look and see what we can make best use of.

Thanks again!

@mattdyoung mattdyoung added the needs discussion Requires internal analysis/discussion label Jan 7, 2021
@chhabrakadabra
Copy link

Any progress on this? I think this would be a fantastic improvement.

@luke-belton
Copy link
Member

hey @chhabrakadabra - we're still tracking this internally and plan to take a look when priorities allow. We'll update this thread as soon as we have any more info 👍

@GuillaumeCrowdcomfort
Copy link

Anything outside people could contribute?

@luke-belton
Copy link
Member

Hi @GuillaumeCrowdcomfort - did you have anything specific in mind in terms of what you'd wish to contribute here?

@luke-belton luke-belton added the awaiting feedback Awaiting a response from a customer. Will be automatically closed after approximately 2 weeks. label Oct 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting feedback Awaiting a response from a customer. Will be automatically closed after approximately 2 weeks. needs discussion Requires internal analysis/discussion
Projects
None yet
Development

No branches or pull requests

5 participants