gh-70186: Fix doctest badly handling unwrapable objects by BoboTiG · Pull Request #14756 · python/cpython (original) (raw)
[EuroPython 2019]
For some reason, an object could raise an error different from AttributeError
when checking for its __wrapped__
attribute.
This patch silences any errors coming from the underlying call to inpect.unwrap()
and, if verbose
is set to True
, prints out the exception.
Thanks to @mpaolini for helping me with the reproduction test case.
As of the current patch state, I followed R. David Murray (I do not find his GH nick) sentence from his last comment on the BPO:
it should be capturing that and probably other errors and reporting them, instead of just producing a traceback, I think.
Another solution would be to patch inspect.unwrap()
like:
diff --git a/Lib/inspect.py b/Lib/inspect.py index 99a580bd2f..f359b0558a 100644 --- a/Lib/inspect.py +++ b/Lib/inspect.py @@ -507,11 +507,16 @@ def unwrap(func, *, stop=None):
"""
if stop is None:
def _is_wrapper(f):
else:def __is_wrapper(f): return hasattr(f, '__wrapped__')
def _is_wrapper(f):
def __is_wrapper(f): return hasattr(f, '__wrapped__') and not stop(f)
- def _is_wrapper(f):
try:
return __is_wrapper(f)
except Exception:
f = func # remember the original func for error reportingreturn False
Memoise by id to tolerate non-hashable objects, but store objects to
ensure they aren't destroyed, which would allow their IDs to be reused.
But we then loose details and nobody could know that there is an issue somewhere.
I did not want to raise a specific error from there only for doctest (but it is still totally doable).
Yet another solution would to raise from doctest instead of printing. Such as:
raise ValueError(f"DocTestFinder.find: wrapped threw {exc!r}: {type(val)!r}")
As it is done few lines below when doctest cannot deal with certain objects or certains conditions.
This would keep some uniformization in how doctest handle bad cases.
👀 I need external eyes to decide on what is the best solution to use :) (I had to leave the sprints before having time to speak with a core dev)