Closed jdemeyer closed 4 weeks ago
Current sagews traceback does print function names for the current call stack. It also includes line numbers, but these are after preparsing from sage to python2, and are relative to the start of the compiled code block, which may be somewhere in the middle of a code cell.
Only the source for the block being executed at the time of the exception is readily available, and this is, as noted
Displaying code farther down the call stack probably requires restructuring sage execution, because code cells are executed a block at a time in a sage worksheet, generally around this line in sage_server.py. When code is compiled in this way, source code is not available. Since functions may be redefined within several code cells, attempting to retrieve source code after an exception is thrown by naively consulting the worksheet file would not be reliable.
Tagging this as wontfix, because it will be fixed indirectly by creating a sage worksheet style mode (and kernel) for Jupyter notebooks. That will be https://github.com/sagemathinc/cocalc/issues/6374. Then output (e.g., stack traces) will come from Jupyter.
I recently (as in: today) tried using sagews for serious work. One thing which I noticed quickly is that no code is shown in tracebacks:
How am I supposed to find out which line is raising that exception? Manually looking up line numbers doesn't work because empty lines are not counted somehow (presumably, sagews preprocesses input to remove empty lines).
I find this issue so bad that it effectively makes sagews unusable for serious work... I honestly cannot understand why nobody else finds this a huge problem.
If you want to fix this, the standard solution is interfacing with linecache.