-
-
Notifications
You must be signed in to change notification settings - Fork 556
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
Simplify TestSuite's some_elements role and logic (no random sampling) #16244
Milestone
Comments
Commit: |
New commits:
|
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Reviewer: Travis Scrimshaw |
comment:5
LGTM (also with #15919). |
Changed branch from u/nthiery/simplify_testsuite_s_some_elements_role_and_logic__no_random_sampling_ to |
comment:8
See #23724 for adding this back in (but optionally) |
Changed commit from |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Since #14284,
TestSuite
(more preciselyInstanceTester.some_elements
) tries to be fancy by choosing "some elements" using a random sample. The random sample is built using Python'srandom.sample
, which requires its input to be a Sequence (i.e. the i-th element can be fetched with o[i]), or some dict-like object. This can get brittle with inputs where__getitem__
is used for other purposes, or where unranking is just computationally expensive. Thesome_elements
method also assumes__len__
to be implemented and cheap enough.Example:
This ticket reduces the role of
InstanceTester.some_elements
to just do some argument parsing and ensure that at most "max_run" elements are returned. It only requires the input to be iterable.If we want to have fancy random samples, we should define a specific protocol (typically P.sample()) for it, or just let parents decide on the strategy by defining some_elements appropriately.
This was originaly analyzed in #15919.
TODO: decide whether InstanceTester.some_elements should return a list or an iterator. A list would be more user friendly (though that's not critical since this is pretty low level) and maybe less error-prone (if a _test_method attempt to reuse the result twice). On the other hand, in case of failure of a _test_method, using an iterator would waste a bit less time before the failure occurs (no need to build all the elements).
CC: @mezzarobba @sagetrac-sage-combinat @roed314 @saraedum
Component: doctest framework
Author: Nicolas M. Thiéry
Branch:
2486f80
Reviewer: Travis Scrimshaw
Issue created by migration from https://trac.sagemath.org/ticket/16244
The text was updated successfully, but these errors were encountered: