On Sat, May 29, 2021 at 3:38 PM Irit Katriel <iritkatr...@yahoo.com> wrote:
> See this issue: https://bugs.python.org/issue31299 > > This issue refers to https://bugs.python.org/issue16217 which talks about lines "above" the one of interest (compared with those that I describe as being "below"). It also talks about filtering some specific modules -- something I already do in one of my projects. Still, interesting to see; thanks for the link. > > > On Saturday, May 29, 2021, 07:19:32 PM GMT+1, André Roberge < > andre.robe...@gmail.com> wrote: > > > With CPython, tracebacks obtained from code written in C can be extremely > clean compared with functionally equivalent code written in Python. > Consider the following test file where I am using a local copy of Python's > datetime.py module. > > ```py > from local_datetime import date > d = date(2021, 13, 1) > ``` > > Executing this code results in the following, very "clean" traceback: > ```pytb > Traceback (most recent call last): > File "test.py", line 2, in <module> > d = date(2021, 13, 1) > ValueError: month must be in 1..12 > ``` > > A single line of code is shown, which is the one written by the end-user > of this library; all code details from inside the library module are hidden. > > As it turns out, the datetime module imports (if it is available) the > _datetime module written in C. If we comment out this import, so that the > pure Python code is used instead, > here is the new traceback: > > ```pytb > 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 847, in __new__ > year, month, day = _check_date_fields(year, month, day) > File "C:\Users\andre\local_datetime.py", line 422, in _check_date_fields > raise ValueError('month must be in 1..12', month) > ValueError: ('month must be in 1..12', 13) > ``` > > In addition to the call by the end-user of that library, we see some inner > code of that library that has no practical value to the end-user. > > We can suppress some lines of the traceback by replacing the line > > ```py > year, month, day = _check_date_fields(year, month, day) > ``` > by > ```py > try: > year, month, day = _check_date_fields(year, month, day) > except Exception: > _, _, tb = sys.exc_info() > tb.tb_next = None > raise > ``` > > which simplifies the traceback somewhat: > ```pytb > 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 848, in __new__ > year, month, day = _check_date_fields(year, month, day) > ValueError: ('month must be in 1..12', 13) > ``` > but there is still one line of code from inside the library. > === > Idea: it would be nice if one could somehow define **callables** with a > custom attribute that > would indicate that tracebacks should not include frames "below" it. > More explicitly, using the notation of the above example, imagine that we > could write > > ```py > date.__hide_tb__ = True > ``` > and that any call to `date()` that generate a traceback would not show > frames below the > calling frame, thus reproducing what we see when using the C code in this > example. > For library writers, this would be easily reverted when attempting to > debug. > For end users, this would result in much more readable tracebacks, > unencumbered by extra lines of code that are outside of their control. > > André Roberge > > > > > > > > > _______________________________________________ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/WQN7QJUVV62IO3J7ALOJYHS6URYVRDFD/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/3XCRIWFK6NB6WCY3KJZZXNI2TSDMH7WF/ Code of Conduct: http://python.org/psf/codeofconduct/
