Hello, 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 occurs: https://bugs.python.org/issue15110 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 representations). 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. Regards Antoine.
On 15/04/2019 22.07, Antoine Pitrou wrote:
Zope has a feature like that for more than a decade. Code could define variables __traceback_info__ and __traceback_supplement__ in local scope, which would then be used by the traceback formatter to annotate the traceback with additional information. I think it was also possible to hide frame with a similar technique. https://zopeexceptions.readthedocs.io/en/latest/narr.html
This is a really great idea. I’d also point to the awful hacks that jinja2 needs to go through to elide jinia2 frames from user tracebacks as an indicator that this is a desired feature. https://github.com/pallets/jinja/blob/master/jinja2/debug.py On Mon, Apr 15, 2019 at 2:08 PM Antoine Pitrou <solipsis@pitrou.net> wrote:
On Mon, Apr 15, 2019 at 5:07 PM Antoine Pitrou <solipsis@pitrou.net> wrote:
For the "teaching" aspect, I have just started about a week ago working on a project which aims to produce more useful tracebacks for beginners. (This work builds from a slightly different project I had started quite a bit earlier.) For example, you can see some "simplified" tracebacks for general exceptions: https://aroberge.github.io/friendly-traceback/docs/html/tracebacks_en.html as well as for the not very informative "SyntaxError: invalid syntax". https://aroberge.github.io/friendly-traceback/docs/html/syntax_tracebacks_en... If you go to these links, you will see on the following pages a version of the same but translated into French. For those that read only the English version, you may find that it is sometimes repetitive. However, the original message included in a traceback is shown "as is", and is later rewritten in a way meant to be translated: there is no such duplication in languages other than English. Ultimately, one could translate these in any language. My ultimate goal is to provide similar simplified explanations for all standard exceptions in Python, including some that are specific to specialized modules (Turtle and Decimal come to mind), as well as providing an easy way for Library writers to hook into this framework. This does not address the full problem you raise, but I thought it might provide an additional viewpoint to this discussion.
This would need a lot more thinking, and perhaps exploring what kind of hacks already exist in the wild to achieve similar functionality.
I guess my project could be thought of as one of these hacks. André Again, I'm just throwing this around for others to play with.
At work I've implemented a super simple system where frames with file names that match some simple patterns are put in bold. This helps enormously while not hiding information that can be crucial at times. I'd recommend people try this approach and see how it feels. It's very easy to implement compared to the alternatives suggested so far in this thread. I'd also argue that even if the more complex hiding methods mentioned are implemented then this method can still be very useful on top of those other changes. / Anders
On 15/04/2019 22.07, Antoine Pitrou wrote:
Zope has a feature like that for more than a decade. Code could define variables __traceback_info__ and __traceback_supplement__ in local scope, which would then be used by the traceback formatter to annotate the traceback with additional information. I think it was also possible to hide frame with a similar technique. https://zopeexceptions.readthedocs.io/en/latest/narr.html
This is a really great idea. I’d also point to the awful hacks that jinja2 needs to go through to elide jinia2 frames from user tracebacks as an indicator that this is a desired feature. https://github.com/pallets/jinja/blob/master/jinja2/debug.py On Mon, Apr 15, 2019 at 2:08 PM Antoine Pitrou <solipsis@pitrou.net> wrote:
On Mon, Apr 15, 2019 at 5:07 PM Antoine Pitrou <solipsis@pitrou.net> wrote:
For the "teaching" aspect, I have just started about a week ago working on a project which aims to produce more useful tracebacks for beginners. (This work builds from a slightly different project I had started quite a bit earlier.) For example, you can see some "simplified" tracebacks for general exceptions: https://aroberge.github.io/friendly-traceback/docs/html/tracebacks_en.html as well as for the not very informative "SyntaxError: invalid syntax". https://aroberge.github.io/friendly-traceback/docs/html/syntax_tracebacks_en... If you go to these links, you will see on the following pages a version of the same but translated into French. For those that read only the English version, you may find that it is sometimes repetitive. However, the original message included in a traceback is shown "as is", and is later rewritten in a way meant to be translated: there is no such duplication in languages other than English. Ultimately, one could translate these in any language. My ultimate goal is to provide similar simplified explanations for all standard exceptions in Python, including some that are specific to specialized modules (Turtle and Decimal come to mind), as well as providing an easy way for Library writers to hook into this framework. This does not address the full problem you raise, but I thought it might provide an additional viewpoint to this discussion.
This would need a lot more thinking, and perhaps exploring what kind of hacks already exist in the wild to achieve similar functionality.
I guess my project could be thought of as one of these hacks. André Again, I'm just throwing this around for others to play with.
At work I've implemented a super simple system where frames with file names that match some simple patterns are put in bold. This helps enormously while not hiding information that can be crucial at times. I'd recommend people try this approach and see how it feels. It's very easy to implement compared to the alternatives suggested so far in this thread. I'd also argue that even if the more complex hiding methods mentioned are implemented then this method can still be very useful on top of those other changes. / Anders
participants (6)
-
Anders Hovmöller -
Andre Roberge -
Antoine Pitrou -
Christian Heimes -
Nathan Goldbaum -
Terry Reedy