pyscript: Incorrect line number in exception tracebacks

Checklist

I added a descriptive title
I searched for other issues and couldn’t find a solution or duplication
I already searched in Google and didn’t find any good information or help

What happened?

When a RuntimeError is raised on line 1 of the default main.py, the following output is displayed on the console:

Traceback (most recent call last):
  File "/lib/python311.zip/_pyodide/_base.py", line 501, in eval_code
    .run(globals, locals)
     ^^^^^^^^^^^^^^^^^^^^
  File "/lib/python311.zip/_pyodide/_base.py", line 339, in run
    coroutine = eval(self.code, globals, locals)
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "<exec>", line 45, in <module>
RuntimeError: raised at line 1

So there is an offset of 44. This offset does not depend on the placement of the <script src="/.main.py" ...> tag. Switching to a different pyodide version (using interpreter = ... in pyscript.toml) also appears to give the same result.

For reference; when I run the same main.py with my local ©python 3.11.2 interpreter, this is what I see:

Traceback (most recent call last):
  File "/path/to/some/project/main.py", line 1, in <module>
    raise RuntimeError('raised at line 1')
RuntimeError: raised at line 1

See https://pyscript.com/@jorenham/bug-traceback-line-numbers/v1 for a reproducible example.

What browsers are you seeing the problem on? (if applicable)

No response

Console info

No response

Additional Context

No response

About this issue

Original URL
State: closed
Created 5 months ago
Comments: 18 (10 by maintainers)

Commits related to this issue

Fix #1972 - Evaluate users' code a part — committed to WebReflection/pyscript by WebReflection 5 months ago
Fix #1972 - Evaluate users' code a part — committed to WebReflection/pyscript by WebReflection 5 months ago
Fix #1972 - Evaluate users' code a part — committed to WebReflection/pyscript by WebReflection 5 months ago
Fix #1972 - Evaluate users' code a part — committed to WebReflection/pyscript by WebReflection 5 months ago
Fix #1972 - Evaluate users' code a part — committed to WebReflection/pyscript by WebReflection 5 months ago
Fix #1972 - Evaluate users' code a part — committed to WebReflection/pyscript by WebReflection 5 months ago
Fix #1972 - Evaluate users' code a part (#1975) — committed to pyscript/pyscript by WebReflection 5 months ago

Most upvoted comments

@jorenham so here are the blockers for that approach:

multiple scripts cannot land in the same file on the VFS or there will be more confusion than we try to solve
because all pyscript tags share the same runtime, it’s not clear how to signal one script, instead of another one, produced the error … DOM insertion order? what if it’s an event defined in script 2 but not script 1?
if you do care about precise line error you can already saver your file as .py, write that file in the config.toml or config.json or <py-config> as file to store in the VFS and then you do import thing.py as __thing in your code … this is the cleanest approach to me and it already works
it is possible that we might want to improve bootstrap and teardown of each script but hooks can happen at distance because scripts can be appended dynamically … right now expectations (and/or bugs based on these expectations) are consistent across all possible scenarios … branching logic here and there might lead to more issues …

After thinking about it a bit more, I think the multiple run approach would better reflect expectations and be actually easier to implement or reason about: your code that might fail runs within a dedicated chunk of Python that should be well defined in terms of lines.

I want to see how bad of a performance impact the multiple approach has and, if that’s not the case, I think that’s the best we can offer:

it works with multiple scripts using the same pyodide interpreter (or MicroPython)
it doesn’t change too much logic around hooks before or after code
it evaluates a part the program as main entry point without ever conflicting with the DOM position of the script or the numerically incremented __mainX all things that tell users nothing useful …

As summary: do you think evaluating user code in between a run (or runAsync) for hooks and stdlib would solve your issue?

WebReflection on Feb 8, 2024