On Tue, Feb 11, 2020 at 5:19 AM Andrew Barnert via Python-ideas <python-ideas@python.org> wrote: > Meanwhile, for the implementation side, I don’t think there’s an issue with > how traceback passes data around, but with what’s available in the first > place. Look at what gets stored as line number information in a compiled code > object. (You don’t want to read the whole details on how the lnotab is built > or anything; just `dis.dis` some code.) Given the offset of an opcode, is > there a correct algorithm to get the range of line numbers for the full > expression that opcode is part of? If not, the only way traceback could do it > would be re-parsing the body of the scope, which I don’t think you’d want to > do. (At least not in general—in some applications it might be useful, and a > PyPI library that hooked trackbacks to do that plus adding all kinds of > useful heuristics might be nifty.) >
Lemme put a slightly different spin on that. The traceback currently has the line number from the compiled code, and while it might be a bit of extra work to figure out exactly when to expand, this could be done entirely in userspace (eg as an excepthook), and could be an incredibly useful library. It wouldn't need any language changes, and could be published on PyPI as a straight-forward way to improve tracebacks in large applications. (I don't think this would be useful in the general case (there's a lot of times when I'd rather have a compact traceback than the expanded one), but you could easily activate this in any sort of application where it'd be helpful.) ChrisA _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/TWVOBA4Y7JNWZU3JZK2UOKS37WDHK5UZ/ Code of Conduct: http://python.org/psf/codeofconduct/
