hypothesis icon indicating copy to clipboard operation
hypothesis copied to clipboard
verified publisher icon HypothesisWorks

Stack depth of return-type warning in @composite strategy

Open reaganjlee opened this issue 1 year ago • 1 comments

Fixes issue #3985

I checked where the frames pointed to and it seemed that pointing back to the user code seemed most reasonable. If we were to point to internal hypothesis code, the best for py3.10/3.11: stackdepth=3 at core.py, line 1893 for def composite(f: Callable[..., Ex]) -> Callable[..., SearchStrategy[Ex]]:. The best for py3.12: stackdepth=1 at core.py, line 1888 for return _composite(f).

reaganjlee avatar Jun 29 '24 23:06 reaganjlee

Seems the failing tests are all non-osx issues. Is there any recommended way to work on these from a mac without it being too involved on setup?

reaganjlee avatar Jun 30 '24 00:06 reaganjlee

Two reasonable options:

  1. just read the CI logs, push, and it'll run that way.
  2. run the TASK=... ./build.sh command that CI runs; most of them will behave identically on OSX as Linux - we just run all the library-specific stuff on Linux because the worker instances are so much cheaper. And if this is troublesome for something, go to (1).

Zac-HD avatar Jul 01 '24 06:07 Zac-HD

I'm not really sure what the differences are between the non-flaky failing cases and similar passing cases (check-py310-cover). The setup process looked pretty identical besides additional info about their respective, unrelated packages. Any tips?

reaganjlee avatar Jul 06 '24 08:07 reaganjlee

I'm not really sure what the differences are between the non-flaky failing cases and similar passing cases (check-py310-cover). The setup process looked pretty identical besides additional info about their respective, unrelated packages. Any tips?

Me neither :shrug: , but a possible way forward might be to (temporarily) print the whole stack and then force-fail this test, to see which stackframe is added/removed.

jobh avatar Jul 11 '24 09:07 jobh

I'm not really sure what the differences are between the non-flaky failing cases and similar passing cases (check-py310-cover). The setup process looked pretty identical besides additional info about their respective, unrelated packages. Any tips?

Me neither 🤷 , but a possible way forward might be to (temporarily) print the whole stack and then force-fail this test, to see which stackframe is added/removed.

That should already be done here in this test. They can be pointed to the right frame but the question seems to be what condition to check for to fix it. Thank you for the suggestion though!

Since this is such a small issue that seems difficult to fix, I'll just be leaving this here. Looking to make more progress on other potential PRs!

reaganjlee avatar Jul 15 '24 09:07 reaganjlee