Martin <martin.schroe...@nerdluecht.de> added the comment:
I see two scenarious discussed here: Scenario 1 (Offline / Batch-Mode): A system runs user-supplied jobs that may fail. In the case of an error, the system shouldn't crash but rather store a maximally helpful message and carry on with the next job. Most likely, the relevant information is the situation that lead to the error in the first place, not that repr() has also gone wrong as a result. This could be a a system to automatically test the homework code of your students. Or, like in my case, a framework that runs experiments. You would very likely want a system that does not crash if a __repr__ is wrongly implemented but prints a readable traceback and carries on with the next job. Here, format_locals could be used to fall back to a different representation of an object if repr() fails. This is the use case that my pull request tries to address primarily. Scenario 2 (Online / Write, Test, Repeat): A user frequently rewrites and executes their code until the desired outcome appears. Errors inevitably happen. In this case, a maximally helpful stack trace is needed. Again, the relevant information is the situation that lead to the error in the first place, not that repr() has also gone wrong as a result. Yes, it would be hard for unexperienced users to come up with StackSummary.extract(format_locals=...) by themselves. But, the correct way would be to use a debugger anyway, not some hand-written code to print exceptions on the fly. However, if your students receive a template file where they fill in missing function bodies etc, there might already be a substantial amount of code which they don't understand at first, nor do they need to care. Therefore, a piece of code that formats exceptions nicely would hurt here. I think the most useful change for Scenario 2 (if, for some reason, a proper debugger is not an option) could be to add a command line option (e.g. -X capture_locals) so that a complete stack trace is printed if an exception bubbles up to interpreter level. (Here, it wouldn't hurt to handle exceptions in repr() because the interpreter already stopped exection anyway.) This option would be very easy to teach to inexperienced users. My pull request would provide preparation for this more extensive change. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue43656> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
