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/

Reply via email to