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 <solip...@pitrou.net> wrote: > > 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. > > > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
