search

scipy / scipy_doctest

Floating-point aware doctesting
BSD 3-Clause "New" or "Revised" License
5 stars 4 forks source link

ENH: make OutputChecker pluggable #141

Closed ev-br closed 5 months ago

ev-br commented 5 months ago

Add CheckerKlass attribute to DTConfig for the class name of the Checker, use in instantiating the Runner. Then it percolates all the way up to all sorts of frontends, both doctest and pytest layers.

DTConfig gets a bit crowded, and it becomes easy to silently ignore some keys: VanillaOutputChecker ignores atol/rtol etc. If this ever becomes a problem, can add more structure to DTConfig. The right thing is likely to make DTConfig hold actual objects not classes and their instantiation parameters. That would be a larger change though, so let's get there when it gets more usage. Until then, let's keep it simple.

cross-ref gh-38.

ev-br commented 5 months ago

cc @Sheila-nk

ev-br commented 5 months ago

Note to self: with this and alternate DTParsers, the docs should shift the focus a bit. First discuss that everything is pluggable (Checker, Parser, Finder), then get on to the fp-aware Checker.

Now that I think of it, the Finder is a bit different: the main logic is in find_doctests, so maybe it should be split into a separate Finder? Not sure.

Sheila-nk commented 5 months ago

The right thing is likely to make DTConfig hold actual objects not classes and their instantiation parameters.

Maybe before we get to this, we can override the vanilla OutputChecker to have an initfunction like you did during testing. What do you think?

ev-br commented 5 months ago

Maybe before we get to this, we can override the vanilla OutputChecker to have an initfunction like you did during testing. What do you think?

Not sure what OutputChecker you mean? All in all I wouldn't rush changing the way DTConfig is organized. WHat's there now seems to work, and enhancements very well might be YAGNI.

ev-br commented 5 months ago

Merged it, thanks for the review Sheila!