raise None

Rustom Mody rustompmody at gmail.com
Mon Jan 4 06:55:58 EST 2016


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.



More information about the Python-list mailing list