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@egenix.com> wrote:
Antoine Pitrou wrote:
On Sat, 26 Jun 2010 13:03:38 +0200 "M.-A. Lemburg" <mal@egenix.com> wrote:
Greg Ewing wrote:
ghazel@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@python.org http://mail.python.org/mailman/listinfo/python-ideas
-- --Guido van Rossum (python.org/~guido)