On Monday, January 4, 2016 at 11:23:24 AM UTC+5:30, Rustom Mody wrote: > On Monday, January 4, 2016 at 10:49:39 AM UTC+5:30, Steven D'Aprano wrote: > > On Fri, 1 Jan 2016 10:27 am, Ben Finney wrote: > > > > > If I could have the traceback continue into the C code and tell me the > > > line of C code that raised the exception, *that's* what I'd choose. > > > > If you are serious about believing this would be a good thing, you can open > > a ticket on the bug tracker and make an enhancement request that tracebacks > > generated from builtins should expose their internal details: > > > > > > >>> 7 + [] > > Traceback (most recent call last): > > File "<stdin>", line 1, in <module> > > File "longobject.c", line 3008, in long_add > > File "longobject.c", line 1425, in CHECK_BINOP > > TypeError: unsupported operand type(s) for +: 'int' and 'list' > > > > > > When you open that ticket, be so good as to add me to the Nosy list. > > Prior Art: > An emacs lisp error stops at the boundaries of emacs lisp if I use standard > (debian/ubuntu packaged) emacs. > OTOH if compiled from source it points to the C source (last I remember > trying)
I think I mis-remembered this: It is not tracebacks but docs that reach from front-facing lisp (commands) through internal lisp (functions) to C in elisp. -- https://mail.python.org/mailman/listinfo/python-list
