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

[M.-A. Lemburg]

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/