On Thu, Jul 13, 2017 at 8:14 AM, Pauli Virtanen <pav@iki.fi> wrote:

Charles R Harris kirjoitti 12.07.2017 klo 13:53:
> In practice, that would generally be true, but the nose testing tools
> were 1, all nose imports were buried in functions that ran during
> testing. Whether or not that was by intent I don't know. But having an
> explicit consensus on 2, which seems to be the case here, is helpful
> because it allows better use of pytest fixtures.

I guess the question is about shipping new pytest fixtures as a part of
the public API of numpy.testing, for use by 3rd party projects.

Agreed. That's a different question, and I'd prefer to keep things as they are in that respect. Otherwise it's basically a hard dependency of numpy itself on pytest.

If the issue is only with Numpy's own tests, they can import stuff from
a private submodule that's not imported by "import numpy.testing", so it
does not introduce a dependency.

(Similar thing for the public API might also be possible e.g. "import
numpy.testing.pytest_fixtures" but it comes at the cost of a new submodule.)

So I guess a main question actually is: how much of the public API in
numpy.testing should be ported to pytest for use by 3rd projects?

The numerical assert functions are obviously useful.

The warnings suppression (pytest warning stuff IIRC doesn't deal with
warning registries nor work around the bugs in warnings.catch_warnings)
similarly --- it could make sense to actually upstream it...

But I'm not so clear about the rest.

Agreed, nothing in the decorators that obviously needs a pytest-based implementation. The Tester class may be the one thing.

Ralf