Skip to content

gh-70186: Fix doctest badly handling unwrapable objects #14756

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

BoboTiG
Copy link
Contributor

@BoboTiG BoboTiG commented Jul 13, 2019

[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):
+        def __is_wrapper(f):
             return hasattr(f, '__wrapped__')
     else:
-        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:
+            return False
     f = func  # remember the original func for error reporting
     # 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)

https://bugs.python.org/issue25998

@aeros
Copy link
Contributor

aeros commented Jul 13, 2019

cc @bitdancer (R. David Murray), @stevendaprano

Copy link
Contributor

@aeros aeros left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm significantly more in favor of raising an explicit exception message from the doctests. The usage of:

try:
    ...
except Exception:
    return False

is generally frowned upon, as far as I'm aware.

@aeros
Copy link
Contributor

aeros commented Jul 14, 2019

Also, thanks for the contribution!

@BoboTiG
Copy link
Contributor Author

BoboTiG commented Jul 15, 2019

@aeros167 Changes done 👍

Copy link
Contributor

@aeros aeros left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good as far as I can tell, thanks for making the suggested changes. Since there's no active core dev expert on the doctests in the expert index I'll mention some others. Three of them are listed as other test experts and vstinner is experienced with writing tests in general.

cc @ezio-melotti @voidspace @vstinner @rbtcollins

@furkanonder
Copy link
Contributor

furkanonder commented Apr 6, 2023

LGTM. Can you resolve the merge conflict? @BoboTiG

@BoboTiG
Copy link
Contributor Author

BoboTiG commented Apr 6, 2023

I fixed conflicts, but it seems doctest source code has changed since 2019 :)
I'll check again more deeply, I even think the issue was fixed in-between, and that PR would be then useless. LMC, and come back to you later in the week, or the next.

@BoboTiG BoboTiG changed the title bpo-25998: Fix doctest badly handling unwrapable objects gh-70186: Fix doctest badly handling unwrapable objects Nov 29, 2024
@BoboTiG BoboTiG force-pushed the fix-bpo-25998-doctest-unwrapable-obj branch from 89c79fd to 0e5672d Compare November 29, 2024 09:25
@BoboTiG
Copy link
Contributor Author

BoboTiG commented Nov 29, 2024

I finally got time to update the patch, and the CI is still green 🎉

/cc @aeros @furkanonder

@mpaolini
Copy link
Contributor

@BoboTiG shall we land this :) ?

@BoboTiG
Copy link
Contributor Author

BoboTiG commented Mar 12, 2025

@BoboTiG shall we land this :) ?

It's up to the team, the CI is green :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants