[issue19585] Frame annotation

[Nick Coghlan]

Nick Coghlan added the comment:

Another use case from frame annotations: allowing greenlets and threads to 
indicate which greenlet or thread a traceback is from whenever it is printed 
(this is similar to the way the runtime indicates which thread a traceback 
occurred in when it terminates the the thread, but would apply whenever the 
uppermost frame is displayed in a thread that isn't the main thread, or in the 
case of greenlets, the uppermost frame in the greenlet, always)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19585] Frame annotation

[Nick Coghlan]

Nick Coghlan added the comment:

A nested function will always share the code object between its instances -
the nested code object is a compile time constant stored as part of the
containing code object.

Any code object attribute must be consistent for the lifetime of the object.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19585] Frame annotation

[Walter Dörwald]

Walter Dörwald added the comment:

Do you have an example where code objects are shared? We could attach the 
annotation formatter to the function object, but unfortunately the function 
object is now accessible in the traceback.

Note the co_annotation is not the annotation string, rather it is a function 
that does the formatting of the annotation.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19585] Frame annotation

[Nick Coghlan]

Nick Coghlan added the comment:

Code objects are shared amongst multiple function objects, so you
can't store mutable state on them.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19585] Frame annotation

[Walter Dörwald]

Walter Dörwald added the comment:

Here is a new version of the patch. The annotation is done on the code object 
instead of on the frame object. This avoids two problems: There is no runtime 
overhead, as the decorator returns the original function and no additional 
frames show up in the traceback. Since the variables are only known at runtime, 
the annotation is now a function that does the formatting of the annotation 
message and gets passed the frame object. With this there is no runtime 
overhead when no exception is raised and even if an exception is raise, but the 
traceback is never formatted.

--
Added file: http://bugs.python.org/file32834/code-annotation.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19585] Frame annotation

[Nick Coghlan]

Nick Coghlan added the comment:

Aye, it would. The improved exception chaining and frame hiding ideas in
issue 18861 are also related.

The part I particularly like in Walter's suggestion is the idea of a "frame
description" that is displayed in the traceback for that frame, without the
traceback module needing to know the details of other annotations.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19585] Frame annotation

[Antoine Pitrou]

Antoine Pitrou added the comment:

I think this would need a PEP.

--
nosy: +ncoghlan, pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19585] Frame annotation

[Walter Dörwald]

Walter Dörwald added the comment:

See http://bugs.python.org/issue18861 and the discussion started here: 
https://mail.python.org/pipermail/python-dev/2013-November/130155.html.

Basically it allows to add context information to a traceback without changing 
the type of the exception.

In the following example:

   import itertools
   ', '.join(itertools.chain((str(i) for i in range(100)), [42]))

the join method itself adds context information to the TypeError:

   Traceback (most recent call last):
 File "hurz.py", line 2, in 
   ', '.join(itertools.chain((str(i) for i in range(100)), [42]))
   TypeError: sequence item 100: expected str instance, int found

i.e. the "sequence item 100" is context information.

However when the exception occurs higher up in the call chain, no such context 
information is added:

   import itertools

   def foo(x):
  return str(x+1)

   ', '.join(foo(x) for x in itertools.chain(range(100), [None]))

This gives:

   Traceback (most recent call last):
 File "hurz.py", line 6, in 
   ', '.join(foo(x) for x in itertools.chain(range(100), [None]))
 File "hurz.py", line 6, in 
   ', '.join(foo(x) for x in itertools.chain(range(100), [None]))
 File "hurz.py", line 4, in foo
   return str(x+1)
  TypeError: unsupported operand type(s) for +: 'NoneType' and 'int'

With frame annotations the traceback might look like this:

   Traceback (most recent call last):
 File "hurz.py", line 6, in 
   ', '.join(foo(x) for x in itertools.chain(range(100), [None]))
 File "hurz.py", line 6, in : sequence item 100
   ', '.join(foo(x) for x in itertools.chain(range(100), [None]))
 File "hurz.py", line 4, in foo
   return str(x+1)
  TypeError: unsupported operand type(s) for +: 'NoneType' and 'int'

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19585] Frame annotation

[STINNER Victor]

STINNER Victor added the comment:

What is the use case of frame annotations?

--
nosy: +haypo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue19585] Frame annotation

[Walter Dörwald]

New submission from Walter Dörwald:

This patch adds frame annotations, i.e. it adds an attribute f_annotation to 
frame objects, a decorator to set this attribute on exceptions and extensions 
to the traceback machinery that display the annotation in the traceback.

--
components: Interpreter Core
files: frame-annotation.diff
hgrepos: 214
keywords: patch
messages: 202862
nosy: doerwalter
priority: normal
severity: normal
status: open
title: Frame annotation
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file32614/frame-annotation.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com