tools, tools.calculation: docs/type-hint improvements, API fixes, better test coverage #2543
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This starts with some tweaks to the docstring data in
tools(.. versionadded::kinda stuff) andtools.calculationthat I found sitting in a forgotten branch; apparently those smaller tweaks never reached the point of a full PR.That stalled work's finally done:
sopel/tools/calculation.pyis now fully type-annotated and has 100% test coverage. Along the way I discovered a few API glitches (e.g. incorrectly documented parameter types, missing parameters) and fixed 'em.I admit some of the test assertions are pretty ugly, but with only one custom exception type it's necessary to make sure that the right kind of
ExpressionEvaluator.Erroris being raised. A future refactoring opportunity, that is (which #2508 already tracks).Checklist
make qa(runsmake lintandmake test)Notes
The framework for fully exercising
tools.calculationin tests came from both #2530 and #2464 (comment) — thanks, @SnoopJ! Getting around to this would have taken a lot longer if you didn't kick-start it.Just one thing I haven't cracked: Two new Sphinx warnings from type annotations that it can't resolve to cross-reference links:
Those are, however, the types required to satisfy
mypy. Trying to use the CamelCase classes inast's documentation (BinOpandUnaryOp) never passed type-checking. The class hierarchy there doesn't work like one might think it does (or should).At the moment, I'm ready to give up on these like what eventually happened with the unfixed warnings left over in #2496. Really seems like Sphinx just can't handle certain things. Even the Python docs themselves reference these, and the rendered HTML shows them as
xref py py-classbut they're not linked.