[Python-ideas] feature to make traceback objects usable without references to frame locals and globals

[Guido van Rossum]

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.

--Guido

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
>> exception:
>>
>>>>> try: 1/0
>> ... except Exception as _: e = _
>> ...
>>>>> e.__traceback__
>> <traceback object at 0x7ff69fdbf908>
>
> Ouch.
>
> 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
> anymore.
>
> 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
> eGenix.com
>
> 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
>               http://www.egenix.com/company/contact/
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>



-- 
--Guido van Rossum (python.org/~guido)