[Python-Dev] Reference cycles in Exception.traceback (original) (raw)

Yury Selivanov yselivanov.ml at gmail.com
Thu Mar 6 20:02:52 CET 2014

But having exceptions without 'traceback' affects not only the inspect module, but also lots of other code. It will make harder to write generic error reporting code, as you'd need to check for traceback first, and then, if it's None, look for some other, asyncio specific attribute.

I think that having tracebacks with fake frames is much more backwards compatible and consistent solution. I don't understand why we should break the established protocol here.

[Or we can allow instantiation of immutable frame objects without code]

Yury

On 2014-03-06, 1:32 PM, Guido van Rossum wrote:

But inspect is in the stdlib. Surely changing inspect.py is less controversial than amending the semantics of frame objects.

On Thu, Mar 6, 2014 at 10:10 AM, Xavier Morel <python-dev at masklinn.net>wrote: On 2014-03-06, at 16:52 , Antoine Pitrou <solipsis at pitrou.net> wrote: Le 06/03/2014 16:03, Yury Selivanov a écrit :

On 2014-03-06, 8:42 AM, Antoine Pitrou wrote:

Le 05/03/2014 23:53, Nick Coghlan a écrit :

traceback wouldn't change [...] Uh, really? If you want to suppress all reference cycles, you have to remove traceback.

The problem is to make computation of the traceback summary lightweight enough that it doesn't degrade performance in the common case where you don't have to print the traceback later. So why can't we allow instantiation of types.TracebackType & types.FrameType? IMO it is absolutely out of question to allow creation of arbitrary frames from Python code, because the structure and initialization of frames embody too many low-level implementation details. We might allow the creation of traceback objects, but without any custom frame objects it is unclear how useful that would be. Some bits of the standard library (and probably third-party libraries transitively relying on getinnerframes) really, really want traceback objects and can't be used with a stack or frames extracted via inspect.currentframe() or whatever. For instance cgitb.text calls inspect.getinnerframes which accesses param.tbframe then calls getframeinfo(param). getframeinfo blows up if it does not get either an actual traceback object or an actual frame object. A frame object does not have a tbframe attribute, and will thus fail in getinnerframes, a fake traceback object will fail in getframeinfo. Therefore it's not possible to call cgitb.text outside of an exception handling context (that is, not possible to use it as a traceback.printstack providing extra information). If it were possible to create traceback objects, there would be no issue there at least.

Python-Dev mailing list Python-Dev at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org

Python-Dev mailing list Python-Dev at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/yselivanov.ml%40gmail.com

More information about the Python-Dev mailing list