Changes by STINNER Victor victor.stin...@gmail.com:
--
components: +asyncio
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17911
___
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
___
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
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17911
___
___
Python-bugs-list
Changes by Yury Selivanov yselivanov...@gmail.com:
--
keywords: -easy
nosy: +yselivanov
versions: +Python 3.5 -Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17911
___
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
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
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
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.
--
Changes by Björn Sandberg Lynch adaptivelo...@gmail.com:
Added file: http://bugs.python.org/file30901/traceback2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17911
___
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
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.
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
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.
Antoine Pitrou added the comment:
Ok, I've spinned off the frame clearing suggestion to issue17934.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17911
___
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
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
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
Guido van Rossum added the comment:
On Mon, May 6, 2013 at 6:06 AM, Antoine Pitrou rep...@bugs.python.org 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
Antoine Pitrou added the comment:
On Mon, May 6, 2013 at 6:06 AM, Antoine Pitrou
rep...@bugs.python.org 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
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
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. :-)
--
Changes by Guido van Rossum gu...@python.org:
--
keywords: +easy
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17911
___
___
Python-bugs-list
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
24 matches
Mail list logo
