[Python-ideas] feature to make traceback objects usable without references to frame locals and globals
Guido van Rossum
guido at python.org
Sun Jun 27 01:05:17 CEST 2010
Please don't act so surprised. There are about 4 relevant PEPs: 344,
3109, 3110, 3134 (the latter replacing 344). Also note that the
traceback is only kept alove if the exception object is explicitly
copied out of the except block that caught it -- normally the
exception object is deleted when that block is left.
On Sat, Jun 26, 2010 at 2:53 PM, M.-A. Lemburg <mal at egenix.com> wrote:
> Antoine Pitrou wrote:
>> On Sat, 26 Jun 2010 13:03:38 +0200
>> "M.-A. Lemburg" <mal at egenix.com> wrote:
>>> Greg Ewing wrote:
>>>> ghazel at gmail.com wrote:
>>>>> I'm interested in a feature which allows users to discard the locals
>>>>> and globals references from frames held by a traceback object.
>>> Wouldn't it be better to write safer code and not store
>>> a reference to the traceback object in the first place ?
>> In Python 3, tracebacks are stored as an attribute of the corresponding
>>>>> try: 1/0
>> ... except Exception as _: e = _
>> <traceback object at 0x7ff69fdbf908>
> So you explicitly need get rid off the traceback in Python3 if
> you want to avoid keeping the associated objects alive during
> exception processing ?
> I think that design decision needs to be revisited. Tracebacks
> are needed for error reporting, but (normally) not for
> managing error handling or recovery.
> E.g. it is not uncommon to store exception objects in a list for
> later batched error reporting. With the traceback being referenced
> on those object and the traceback chain keeping references to all
> frames alive, this kind of processing won't be feasible
> What's even more important is that programmers are unlikely
> going to be aware of this detail and its implications.
>>> Also: What's the use case for creating traceback objects
>>> outside the Python interpreter core ?
>> He's not talking about creating traceback objects outside the core, but
>> being able to reuse tracebacks created by the core without keeping alive
>> a whole chain of objects.
> With the question I was referring to the suggestion by
> Greg Ewing in which he seemed to imply that Pyrex and Cython
> create traceback objects.
>> It's a real need when you want to do careful error handling/reporting
>> without wasting too many resources. As already mentioned, Twisted has a
>> bunch of code to work around that problem, since errors can be quite
>> long-lived in a pipelined asynchronous execution model.
> With the above detail, I completely agree. In fact, more than that:
> I think we should make storing the traceback in exception.__traceback__
> optional and not the default, much like .__context__ and .__cause__.
> Marc-Andre Lemburg
> Professional Python Services directly from the Source (#1, Jun 26 2010)
>>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
> 2010-07-19: EuroPython 2010, Birmingham, UK 22 days to go
> ::: Try our new mxODBC.Connect Python Database Interface for free ! ::::
> eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
> Registered at Amtsgericht Duesseldorf: HRB 46611
> Python-ideas mailing list
> Python-ideas at python.org
--Guido van Rossum (python.org/~guido)
More information about the Python-ideas