
Hello, On Sat, 29 May 2021 17:29:26 -0300 André Roberge <andre.roberge@gmail.com> wrote:
On Sat, May 29, 2021 at 4:54 PM Irit Katriel <iritkatriel@yahoo.com> wrote:
You can control what the traceback of exceptions you are emitting:
"raise e.with_traceback(None)" should clear everything before the current frame.
I'm sorry, but I still don't see how. This particular line would still show up.
Traceback (most recent call last): File "test.py", line 2, in <module> d = date(2021, 13, 1) File "C:\Users\andre\local_datetime.py", line 852, in __new__ raise e.with_traceback(None) ValueError: ('month must be in 1..12', 13)
Sorry if I am missing something obvious. In the example I gave, as a user calling date() [from a library], I would only want to see that line show up.
It would be *very* confusing to see something like:
File "some/where/deep.py", line 2123, in <module> foo = bar(x, *y) ValueError: ('month must be in 1..12', 13)
You can start your stopwatch and see how much time it will take you to figure out that "bar" is a variable referencing "date" and sequence "y" has "month" somewhere in it. That already happens in CPython in some places, and it's quite confusing when you hit it: https://mail.python.org/archives/list/python-ideas@python.org/thread/MINLM7B... On the topic of "functions implemented in C provide clean tracebacks", on a couple of occasions, I found them to be terse up to being obfuscated. I really consider one sweet day to be able to implement feature to bring them closer to Python level of user-friendliness, e.g.
Traceback (most recent call last): File "foo.py", line 2, in test builtin_func(a) File "~/projects/foo_module/src1.c", line 34, in builtin_func_impl ValueError("wrong phase of moon")
So it was possible to debug code across C extensions boundary more easily (instead of grepping loads of C code for confusing/generic error messages guessing which one was actually hit). Oh, and btw CPython importlib also implements some traceback obfuscation: https://github.com/python/cpython/blob/bb3e0c240bc60fe08d332ff5955d54197f797... Besides user satisfaction ("clean tracebacks"), I guess it contributes largely to the fact that only a few people know how Python import machinery works and are able to customize it. (At least, I found it pretty hard to work with - you literally need to go thru the entire importlib source code and remove those pesky _call_with_frames_removed() calls, and only then you start to get a picture what breaks where and how it all works together).
Or you can get clever and construct a traceback with only the frames you want.
On Saturday, May 29, 2021, 08:27:18 PM GMT+1, André Roberge < andre.roberge@gmail.com> wrote:
What I am interested in is having a project-agnostic standardised Python way to specify what to show to an end-user when an exception is raised.
-- Best regards, Paul mailto:pmiscml@gmail.com