On Feb 10, 2020, at 09:57, Henk-Jaap Wagenaar <wagenaarhenkj...@gmail.com> wrote: > > Any particular reason this is not possible or done? I'm guessing it would > require quite a bit of restructuring in the traceback object/module
One problem is not the implementation, but the interface: if you expand _every_ step into multiple lines, that annoying 99-line deep traceback where you only care about lines 97-98 becomes an even more annoying 213-line deep trackback where you only care about lines 210-212. The fact that you got one extra line to care about may not make up for the fact that your logs got bigger and you need to increase the scrollback buffer in your terminal. Maybe just showing expanded output for the last entry, or making it configurable, would help that? 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.) _______________________________________________ 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/JSWIXFHBZYJHHWSYEHEVGQSR7VWCJAYE/ Code of Conduct: http://python.org/psf/codeofconduct/
