[Python-ideas] Logical tracebacks
solipsis at pitrou.net
Mon Apr 15 16:07:18 EDT 2019
I apologize because I'm only going to throw a very vague idea and I
don't currently have time or motivation to explore it myself. But I
think it may prove interesting for other people and perhaps spur some
concrete actionable proposal.
With the growing complexity of Python software stacks, the length of
tracebacks is continuously growing and is frequently making debugging
errors and issues more tedious than it should be. This is a
language-agnostic problem. Java software is often mocked for its
ridiculously long tracebacks, but Python might come close in the future.
Especially since Python is often the a language of choice for non
computer science professionals, including but not only as a teaching
language, this would be a problem worth solving. We already recognized
the issue some years ago, and even implemented a focussed fix for one
specific context: the elision of importlib frames when an import error
However, there are many contexts where implementation details would
benefit from being hidden from tracebacks (the classical example being
the internals of framework or middleware code, such as Django, Dask,
etc.). We would therefore have to define some kind of protocol by
which tracebacks can be enumerated, not only as frames, but as logical
execution blocks, comprised of one or several frames each, whose
boundaries would reflect the boundaries of the various logical
execution layers (again: framework, middleware...) involved in the
frame stack. We would probably also need some flag(s) to disable the
feature in cases where the full stack frame is wanted (I imagine
elaborate UIs could also allow switching back and forth from both
This would need a lot more thinking, and perhaps exploring what kind of
hacks already exist in the wild to achieve similar functionality.
Again, I'm just throwing this around for others to play with.
More information about the Python-ideas