Add --doctest-ufunc option to doctest Numpy ufuncs

[lpsinger]

This absorbs the functionality of the pytest-doctest-ufunc package, which was heavily based on pytest-doctestplus to begin with.

pytest-doctest-ufunc will be retired.

Fixes #123.

[mhvk]

This looks very nice to me! Main question is about making numpy a requirement.

[mhvk]

Is this still necessary?

[lpsinger]

What do you mean by 'still'? To the best of my knowledge, this is always necessary to suppress the warning in C if you are declaring a non-static function.

[mhvk]

It's just that I haven't had to do this double declaration (e.g., in pyerfa), and I cannot see any difference in the imports you make...

[lpsinger]

It may not be necessary if you don't have warnings cranked all the way up. I'll try without.

[lpsinger]

The tests are failing due to a warning because I use testdir.copy_example, which was formally added in pytest 6.2. pytest-doctestplus currently requires pytest >= 4.6. Should I port my test so that it works without warnings on pytest 4.6? Or is it OK to bump the required version of pytest to 6.2?

[bsipocz]

pytest 6.2 came out in 2020 Dec, so it's a bit borderlines, but I think it's OK to require it. I'm OTOH would not add numpy as a required dependency, only as an optional.

[pllim]

I am about to bump pytest all the way to 7 at astropy/astropy#12823 😬

[bsipocz]

I am about to bump pytest all the way to 7 at

doctestplus supports much more than astropy core, so if possible I would like to be a bit more conservative here.

[lpsinger]

doctestplus supports much more than astropy core, so if possible I would like to be a bit more conservative here.

OK, fixed now.

[saimn]

Can we just do that by default, without needing a new option ? Is there a downside ?

[lpsinger]

Can we just do that by default, without needing a new option ? Is there a downside ?

Do what by default?

[mhvk]

I think @saimn meant whether we can just check the ufunc docstrings by default rather than have a separate option to turn that part on/off. I guess that makes sense - we're really just ensuring here that docstrings that one would naively expect to be checked are in fact checked.

[lpsinger]

I think @saimn meant whether we can just check the ufunc docstrings by default rather than have a separate option to turn that part on/off. I guess that makes sense - we're really just ensuring here that docstrings that one would naively expect to be checked are in fact checked.

I'm fine either way. Just say the word.

[mhvk]

Hmm, since there doesn't seem a downside, I'd say let's make this automatic!

[saimn]

yes, that's what I meant. I guess the only downside would be the small overhead to check if each function is a ufunc but that should be negligible ?

[lpsinger]

yes, that's what I meant. I guess the only downside would be the small overhead to check if each function is a ufunc but that should be negligible ?

The downside is that someone may have exotic code that messes with and wraps functions in a way that is similar to but incompatible with Numpy, and that triggers the code path to search for docstrings in ufuncs, which for one reason or another happens not to work.

[lpsinger]

Hmm, since there doesn't seem a downside, I'd say let's make this automatic!

Done.

[pllim]

Have you tried running the astropy test suite using this branch?

p.s. Given pytest 7 and scipy 1.8 introduced a whole bunch of warnings, you might want to wait for astropy/astropy#12823 or make sure you don't use the latest releases from pytest nor scipy.

[saimn]

Ok, let's merge this and we will run the astropy test suite with the dev version before making a new release. Thanks @lpsinger.

[lpsinger]

Thank you!

[pllim]

I am going to try this out at astropy/astropy#12853 . Thanks!