[SciPy-Dev] Move some validations as asserts?

Ralf Gommers ralf.gommers at gmail.com
Wed Mar 3 08:14:48 EST 2021


On Tue, Mar 2, 2021 at 10:56 PM Evgeni Burovski <evgeny.burovskiy at gmail.com>
wrote:

> > TL;DR: could we use assert to do validation?
> >
> > In a recent issue (https://github.com/scipy/scipy/issues/13629), the
> cost of validation was raised in context such as optimization.
> > In situations like these, or even when you know how to use the API,
> there are lots of unnecessary validations happening.
> >
> > I would propose a general reflection around validation.
> >
> > Some ideas:
> >
> > A simple approach would be to systematically separate the logic in two:
> core function on one side, user interface on the other. This way the user
> could by-pass all the time the validation.
> > Mock the validations. After some quick tests, it looks like the overhead
> is too big. I could be wrong.
>

I'm not sure what this means exactly.

> Using assert for all validation.
>

One obvious issue is that `python -OO` will remove all asserts, and that's
not what we want (we've had lots of issues with popular web deployment
tools running with -OO by default). Hence the rule has always been "no
plain asserts".

Also, error messages for plain asserts are bad usually.


> The first option sounds best to me.
>

Probably - if we do something, that's likely the best direction. The
question though is how to provide a sensible UX for it, that's nontrivial.
Splitting the whole API is a lot of work and new API surface. There may be
alternatives, such as new keywords or fancier approaches (e.g., cython has
a uniform way of turning off bounds checking and negative indexing with
`cython.boundscheck`, `cython.wraparound`).

We probably need to look at all the types of validation (array-like input,
nan/inf checks, parameter bounds, parameter type checks, etc.) and figure
out how we'd like new code to look. For example, I was toying with the idea
of removing `array_like` input from stats.qmc before we release it, and
just accept plain ndarrays (has other benefits, but removes overhead too).

Cheers,
Ralf



> My 2c,
>
> Evgeni
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/scipy-dev/attachments/20210303/17869f7b/attachment.html>


More information about the SciPy-Dev mailing list