debug.traceback() will often return inaccurate results (compared to the original source code) when a script is running in optimization level 2.
This should be documented clearly so that we don’t waste time writing code which assumes debug information will be accurate and trying to figure out why the debug information is wrong.
(This is just for temporary debugging stuff, I am not trying to build anything permanent that uses the debug information.)
Hi there,
Thanks for the report. I added a note on the unreliability of traceback() as you suggested. Also cleaned up the page quite a bit and made the distinct traceback() and info() functions clearer to comprehend, with code samples.
Take care,
IgnisRBX
Great thanks, but I believe the documentation should be more clear about what kinds of situations can cause an inaccurate traceback.
Having a note like “this can return incorrect results sometimes” is kinda useless because at the end of the day when we’re using the API you’ve provided we are expecting it to provide a useful result. Otherwise we wouldn’t use the API at all.
It would be much more helpful to have at least a rough idea of when we are doing something risky or wrong, so that we can handle things correctly when we are trying to do productive work (e.g. we can just always know to disable optimisations when we are trying to debug something with stack traces, or we can know to avoid using stack traces in that situation and try something else, rather than wasting time finding out that the debug info we are trying to use is inaccurate).
Function inlining causes changes to the call stack, which messes with the result of debug.traceback and debug.info. Inlining can always happen with small functions but it’s not something you can know for sure unless you test it.