[issue17911] Extracting tracebacks does too much work

STINNER Victor added the comment: While trying to fix a similar issue for the asyncio project, I wrote the following code: https://bitbucket.org/haypo/misc/src/ce48d7b3ea1d223691e496e41aca8f5784671cd5/python/suppress_locals.py?at=default I was not aware that a similar approach (attached traceba

[issue17911] Extracting tracebacks does too much work

Raymond Hettinger added the comment: > I think it makes sense to treat this as a completely new > traceback introspection API and ignore the low level details > of the legacy API. That would likely be the cleanest approach. -- nosy: +rhettinger ___

[issue17911] Extracting tracebacks does too much work

Changes by STINNER Victor : -- components: +asyncio nosy: +haypo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue17911] Extracting tracebacks does too much work

Changes by Eric Snow : -- nosy: +eric.snow ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.

[issue17911] Extracting tracebacks does too much work

Changes by Yury Selivanov : -- keywords: -easy nosy: +yselivanov versions: +Python 3.5 -Python 3.4 ___ Python tracker ___ ___ Python-

[issue17911] Extracting tracebacks does too much work

Nick Coghlan added the comment: For dis, we introduced a new rich bytecode introspection API. Ditto for inspect.Signature. I think it makes sense to treat this as a completely new traceback introspection API and ignore the low level details of the legacy API. --

[issue17911] Extracting tracebacks does too much work

Antoine Pitrou added the comment: > When it comes to deferral, we could wrap each line in a different > class than tuple, but this constitutes a public API change (and this > is a *very* widely used library). Even changing to a namedtuple > would cause a lot of grief, since we'd break lots of doc

[issue17911] Extracting tracebacks does too much work

Björn Sandberg Lynch added the comment: I was trying to stay with the established pattern of the existing methods. There are two unrelated issues to solve here - deferring linecache access, and the extract_exception functionality. When it comes to deferral, we could wrap each line in a differe

[issue17911] Extracting tracebacks does too much work

Antoine Pitrou added the comment: I think ExceptionSummary could be the visible API, instead of adding an indirection through a separate global function. Also, I don't think having the "exc_traceback" list of tuples is future-proof. What if we want to add some information to each traceback entr

[issue17911] Extracting tracebacks does too much work

Changes by Björn Sandberg Lynch : Added file: http://bugs.python.org/file30901/traceback2.patch ___ Python tracker ___ ___ Python-bugs-list ma

[issue17911] Extracting tracebacks does too much work

Björn Sandberg Lynch added the comment: After thinking about it, I decided to defer instead of suppress line fetching. Suppressing would still give a traceback later, but not the same as the original. extract_exception is where the meat is. There's a slight quirk in how context works - if cau

[issue17911] Extracting tracebacks does too much work

Antoine Pitrou added the comment: > If we keep a reference to f_globals for each line in the traceback, we > can defer this to later (ideally we'd just keep the __loader__ value, > but that would require changing the linecache interface as well). Or you could add a *new* linecache interface. Ke

[issue17911] Extracting tracebacks does too much work

Guido van Rossum added the comment: In terms of how much freedom you have about changing the internal, I'd check how long ago they were changed. "Internal" APIs that have been stable for many versions tend to have illicit external uses -- but internal APIs that were introduced recently (e.g.

[issue17911] Extracting tracebacks does too much work

Björn Sandberg Lynch added the comment: I've been looking into this as an easy piece to bite off. If I understand Guido correctly, he'd like to defer or suppress the linecache call when getting the tb summary. The problem with deferring is that you need to access f_globals for the loader to wo

[issue17911] Extracting tracebacks does too much work

Antoine Pitrou added the comment: Ok, I've spinned off the frame clearing suggestion to issue17934. -- ___ Python tracker ___ ___ Pyth

[issue17911] Extracting tracebacks does too much work

Antoine Pitrou added the comment: You may want two pieces of stack: the piece of stack that is above and including the catch point, and the piece of stack that is below it. The former is what gets traditionally printed in tracebacks, but the latter can be useful as well (see issue1553375 for a

[issue17911] Extracting tracebacks does too much work

Changes by Guido van Rossum : -- keywords: +easy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue17911] Extracting tracebacks does too much work

Guido van Rossum added the comment: That sounds great, except I'd expect the exception type and str(), since a formatted traceback uses the str() of the exception, not its repr(). Personally I don't think the tuples need to be named, but I won't hold up progress either. :-) -- __

[issue17911] Extracting tracebacks does too much work

Nick Coghlan added the comment: Antoine - I like your idea, but I think it's a separate issue. I agree with Guido that exposing some lower level non-formatting APIs in the traceback module would be helpful. I see Guido's suggestion here as similar to the change we just made in the dis module

[issue17911] Extracting tracebacks does too much work

Antoine Pitrou added the comment: > On Mon, May 6, 2013 at 6:06 AM, Antoine Pitrou > wrote: > > Note that generator cleanup through the frame has a patch in > > issue17807. > > Sadly that doesn't help with my issue. It won't. It's just a building block for the change I've proposed here. -

[issue17911] Extracting tracebacks does too much work

Guido van Rossum added the comment: On Mon, May 6, 2013 at 6:06 AM, Antoine Pitrou wrote: > Note that generator cleanup through the frame has a patch in issue17807. Sadly that doesn't help with my issue. I applied path gen3.patch and ran various versions of the code I have. There's still someth

[issue17911] Extracting tracebacks does too much work

Guido van Rossum added the comment: I'm not snubbing my nose at something that breaks these types of cycles more easily, but I still think that the abstractions offered by the traceback module could be improved. -- ___ Python tracker

[issue17911] Extracting tracebacks does too much work

Antoine Pitrou added the comment: I think instead we may want to add a finalize() or close() method on frame objects which would clear all local variables (as well as dereference the globals dict, perhaps), after having optionally run a generator's close() method (if the frame belongs to a gen

[issue17911] Extracting tracebacks does too much work

New submission from Guido van Rossum: For Tulip I may have to extract tracebacks and store the extracted data, in order to avoid cycles created by the frames referenced in the traceback. I'll be extracting the traceback every time an exception is raised, and in most cases I won't be using the