pytest  uses __tracebackhide__

https://doc.pytest.org/en/latest/example/simple.html#writing-well-integrated-assertion-helpers

Eg anyio sets __tracebackhide__ = __traceback_hide__ = True to remove
internal frames from user Tracebacks

On Sat, 29 May 2021, 19:21 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/MQIGFKW762O2BKXCA5HW7WVSQOI5DPHV/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to