On Thu, Jul 13, 2017 at 8:14 AM, Pauli Virtanen <p...@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
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
