There are ways to "bloat" the set of doctests with minimal impact. For
example, we could create a file "TESTS.py" (for example) in a Sage module,
consisting only of doctests. It would not be included in the reference
manual, not visible when someone does "X.my_favorite_method?" or
"X.my_favor
But I don't know how big a problem the codecov issue is ...
We want to regard the check failure as there is a problem with the PR that
the author should resolve.
Currently the codecov failure triggers the check failure, but no reviewer
and no author regard the codecov failure as a pro
"normal" codepaths ought to be tested. Error processing with try/except blocks
might be hard to test in the 1st place, and less crucial.
On 5 October 2024 14:38:19 BST, Kwankyu Lee wrote:
>
>
> But I don't know how big a problem the codecov issue is ...
>
>
>We want to regard the check fai
On Saturday, October 5, 2024 at 6:38:20 AM UTC-7 Kwankyu Lee wrote:
But I don't know how big a problem the codecov issue is ...
We want to regard the check failure as there is a problem with the PR that
the author should resolve.
Currently the codecov failure triggers the check failur
No comment will be construed as no objection.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on t
On Saturday, October 5, 2024 at 7:47:33 AM UTC-4 Kwankyu Lee wrote:
No comment will be construed as no objection.
I guess I'm not actively developing at this point, and doubtless there are
many untested code paths existing. I do think that on the whole I've found
it pretty useful in the pas
