Re: [Numpy-discussion] NEP 31 — Context-local and global overrides of the NumPy API

[Eric Wieser]

> In other words `np.arange(100)` (but
with a completely different syntax, probably hidden away only for
libraries to use).

It sounds an bit like you're describing factory classmethods there. Is the
solution to this problem to move (leaving behind aliases) `np.arange` to
`ndarray.arange`, `np.zeros` to `ndarray.zeros`, etc - callers then would
use `type(duckarray).zeros` if they're trying to generalize.

Eric

On Mon, Sep 9, 2019, 21:18 Sebastian Berg 
wrote:

> On Mon, 2019-09-09 at 20:32 -0700, Stephan Hoyer wrote:
> > On Mon, Sep 9, 2019 at 6:27 PM Ralf Gommers 
> > wrote:
> > > I think we've chosen to try the former - dispatch on functions so
> > > we can reuse the NumPy API. It could work out well, it could give
> > > some long-term maintenance issues, time will tell. The question is
> > > now if and how to plug the gap that __array_function__ left. It's
> > > main limitation is "doesn't work for functions that don't have an
> > > array-like input" - that left out ~10-20% of functions. So now we
> > > have a proposal for a structural solution to that last 10-20%. It
> > > seems logical to want that gap plugged, rather than go back and say
> > > "we shouldn't have gone for the first 80%, so let's go no further".
> > >
> >
> > I'm excited about solving the remaining 10-20% of use cases for
> > flexible array dispatching, but the unumpy interface suggested here
> > (numpy.overridable) feels like a redundant redo of __array_function__
> > and __array_ufunc__.
> >
> > I would much rather continue to develop specialized protocols for the
> > remaining usecases. Summarizing those I've seen in this thread, these
> > include:
> > 1. Overrides for customizing array creation and coercion.
> > 2. Overrides to implement operations for new dtypes.
> > 3. Overriding implementations of NumPy functions, e.g., FFT and
> > ufuncs with MKL.
> >
> > (1) could mostly be solved by adding np.duckarray() and another
> > function for duck array coercion. There is still the matter of
> > overriding np.zeros and the like, which perhaps justifies another new
> > protocol, but in my experience the use-cases for truly an array from
> > scratch are quite rare.
> >
>
> There is an issue open about adding more functions for that. Made me
> wonder if giving a method of choosing the duck-array whose
> `__array_function__` is used, could not solve it reasonably.
> Similar to explicitly choosing a specific template version to call in
> templated code. In other words `np.arange(100)` (but
> with a completely different syntax, probably hidden away only for
> libraries to use).
>
>
> Maybe it is indeed time to write up a list of options to plug that
> hole, and then see where it brings us.
>
> Best,
>
> Sebastian
>
>
> > (2) should be tackled as part of overhauling NumPy's dtype system to
> > better support user defined dtypes. But it should definitely be in
> > the form of specialized protocols, e.g., which pass in preallocated
> > arrays to into ufuncs for a new dtype. By design, new dtypes should
> > not be able to customize the semantics of array *structure*.
> >
> > (3) could potentially motivate a new solution, but it should exist
> > *inside* of select existing NumPy implementations, after checking for
> > overrides with __array_function__. If the only option NumPy provides
> > for overriding np.fft is to implement np.overrideable.fft, I doubt
> > that would suffice to convince MKL developers from monkey patching it
> > -- they already decided that a separate namespace is not good enough
> > for them.
> >
> > I also share Nathaniel's concern that the overrides in unumpy are too
> > powerful, by allowing for control from arbitrary function arguments
> > and even *non-local* control (i.e., global variables) from context
> > managers. This level of flexibility can make code very hard to debug,
> > especially in larger codebases.
> >
> > Best,
> > Stephan
> >
> >
> >
> >
> > ___
> > NumPy-Discussion mailing list
> > NumPy-Discussion@python.org
> > https://mail.python.org/mailman/listinfo/numpy-discussion
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] NEP 31 — Context-local and global overrides of the NumPy API

[Sebastian Berg]

On Mon, 2019-09-09 at 20:32 -0700, Stephan Hoyer wrote:
> On Mon, Sep 9, 2019 at 6:27 PM Ralf Gommers 
> wrote:
> > I think we've chosen to try the former - dispatch on functions so
> > we can reuse the NumPy API. It could work out well, it could give
> > some long-term maintenance issues, time will tell. The question is
> > now if and how to plug the gap that __array_function__ left. It's
> > main limitation is "doesn't work for functions that don't have an
> > array-like input" - that left out ~10-20% of functions. So now we
> > have a proposal for a structural solution to that last 10-20%. It
> > seems logical to want that gap plugged, rather than go back and say
> > "we shouldn't have gone for the first 80%, so let's go no further".
> > 
> 
> I'm excited about solving the remaining 10-20% of use cases for
> flexible array dispatching, but the unumpy interface suggested here
> (numpy.overridable) feels like a redundant redo of __array_function__
> and __array_ufunc__.
> 
> I would much rather continue to develop specialized protocols for the
> remaining usecases. Summarizing those I've seen in this thread, these
> include:
> 1. Overrides for customizing array creation and coercion.
> 2. Overrides to implement operations for new dtypes.
> 3. Overriding implementations of NumPy functions, e.g., FFT and
> ufuncs with MKL.
> 
> (1) could mostly be solved by adding np.duckarray() and another
> function for duck array coercion. There is still the matter of
> overriding np.zeros and the like, which perhaps justifies another new
> protocol, but in my experience the use-cases for truly an array from
> scratch are quite rare.
> 

There is an issue open about adding more functions for that. Made me
wonder if giving a method of choosing the duck-array whose
`__array_function__` is used, could not solve it reasonably.
Similar to explicitly choosing a specific template version to call in
templated code. In other words `np.arange(100)` (but
with a completely different syntax, probably hidden away only for
libraries to use).


Maybe it is indeed time to write up a list of options to plug that
hole, and then see where it brings us.

Best,

Sebastian


> (2) should be tackled as part of overhauling NumPy's dtype system to
> better support user defined dtypes. But it should definitely be in
> the form of specialized protocols, e.g., which pass in preallocated
> arrays to into ufuncs for a new dtype. By design, new dtypes should
> not be able to customize the semantics of array *structure*.
>
> (3) could potentially motivate a new solution, but it should exist
> *inside* of select existing NumPy implementations, after checking for
> overrides with __array_function__. If the only option NumPy provides
> for overriding np.fft is to implement np.overrideable.fft, I doubt
> that would suffice to convince MKL developers from monkey patching it
> -- they already decided that a separate namespace is not good enough
> for them.
> 
> I also share Nathaniel's concern that the overrides in unumpy are too
> powerful, by allowing for control from arbitrary function arguments
> and even *non-local* control (i.e., global variables) from context
> managers. This level of flexibility can make code very hard to debug,
> especially in larger codebases.
> 
> Best,
> Stephan
> 
> 
> 
> 
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion


signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] NEP 31 — Context-local and global overrides of the NumPy API

[Stephan Hoyer]

On Mon, Sep 9, 2019 at 6:27 PM Ralf Gommers  wrote:

> I think we've chosen to try the former - dispatch on functions so we can
> reuse the NumPy API. It could work out well, it could give some long-term
> maintenance issues, time will tell. The question is now if and how to plug
> the gap that __array_function__ left. It's main limitation is "doesn't work
> for functions that don't have an array-like input" - that left out ~10-20%
> of functions. So now we have a proposal for a structural solution to that
> last 10-20%. It seems logical to want that gap plugged, rather than go back
> and say "we shouldn't have gone for the first 80%, so let's go no further".
>

I'm excited about solving the remaining 10-20% of use cases for flexible
array dispatching, but the unumpy interface suggested here
(numpy.overridable) feels like a redundant redo of __array_function__ and
__array_ufunc__.

I would much rather continue to develop specialized protocols for the
remaining usecases. Summarizing those I've seen in this thread, these
include:
1. Overrides for customizing array creation and coercion.
2. Overrides to implement operations for new dtypes.
3. Overriding implementations of NumPy functions, e.g., FFT and ufuncs with
MKL.

(1) could mostly be solved by adding np.duckarray() and another function
for duck array coercion. There is still the matter of overriding np.zeros
and the like, which perhaps justifies another new protocol, but in my
experience the use-cases for truly an array from scratch are quite rare.

(2) should be tackled as part of overhauling NumPy's dtype system to better
support user defined dtypes. But it should definitely be in the form of
specialized protocols, e.g., which pass in preallocated arrays to into
ufuncs for a new dtype. By design, new dtypes should not be able to
customize the semantics of array *structure*.

(3) could potentially motivate a new solution, but it should exist *inside*
of select existing NumPy implementations, after checking for overrides with
__array_function__. If the only option NumPy provides for overriding np.fft
is to implement np.overrideable.fft, I doubt that would suffice to convince
MKL developers from monkey patching it -- they already decided that a
separate namespace is not good enough for them.

I also share Nathaniel's concern that the overrides in unumpy are too
powerful, by allowing for control from arbitrary function arguments and
even *non-local* control (i.e., global variables) from context managers.
This level of flexibility can make code very hard to debug, especially in
larger codebases.

Best,
Stephan
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] NEP 31 — Context-local and global overrides of the NumPy API

[Ralf Gommers]

On Sun, Sep 8, 2019 at 6:27 PM Nathaniel Smith  wrote:

> On Sun, Sep 8, 2019 at 8:40 AM Ralf Gommers 
> wrote:
> >
> >
> >
> > On Sun, Sep 8, 2019 at 12:54 AM Nathaniel Smith  wrote:
> >>
> >> On Fri, Sep 6, 2019 at 11:53 AM Ralf Gommers 
> wrote:
> >> > On Fri, Sep 6, 2019 at 12:53 AM Nathaniel Smith 
> wrote:
> >> >> On Tue, Sep 3, 2019 at 2:04 AM Hameer Abbasi <
> einstein.edi...@gmail.com> wrote:
> >> >> > The fact that we're having to design more and more protocols for a
> lot
> >> >> > of very similar things is, to me, an indicator that we do have
> holistic
> >> >> > problems that ought to be solved by a single protocol.
> >> >>
> >> >> But the reason we've had trouble designing these protocols is that
> >> >> they're each different :-). If it was just a matter of copying
> >> >> __array_ufunc__ we'd have been done in a few minutes...
> >> >
> >> > I don't think that argument is correct. That we now have two very
> similar protocols is simply a matter of history and limited developer time.
> NEP 18 discusses in several places that __array_ufunc__ should be brought
> in line with __array_ufunc__, and that we can migrate a function from one
> protocol to the other. There's no technical reason other than backwards
> compat and dev time why we couldn't use __array_function__ for ufuncs also.
> >>
> >> Huh, that's interesting! Apparently we have a profoundly different
> >> understanding of what we're doing here.
> >
> >
> > That is interesting indeed. We should figure this out first - no point
> discussing a NEP about plugging the gaps in our override system when we
> don't have a common understanding of why we wanted/needed an override
> system in the first place.
> >
> >> To me, __array_ufunc__ and
> >> __array_function__ are completely different. In fact I'd say
> >> __array_ufunc__ is a good idea and __array_function__ is a bad idea,
> >
> >
> > It's early days, but "customer feedback" certainly has been more
> enthusiastic for __array_function__. Also from what I've seen so far it
> works well. Example: at the SciPy sprints someone put together Xarray plus
> pydata/sparse to use distributed sparse arrays for visualizing some large
> genetic (I think) data sets. That was made to work in a single day, with
> impressively little code.
>
> Yeah, it's true, and __array_function__ made a bunch of stuff that
> used to be impossible become possible, I'm not saying it didn't. My
> prediction is that the longer we live with it, the more limits we'll
> hit and the more problems we'll have with long-term maintainability. I
> don't think initial enthusiasm is a good predictor of that either way.
>
> >> The key difference is that __array_ufunc__ allows for *generic*
> >> implementations.
> >
> > Implementations of what?
>
> Generic in the sense that you can write __array_ufunc__ once and have
> it work for all ufuncs.
>
> >> Most duck array libraries can write a single
> >> implementation of __array_ufunc__ that works for *all* ufuncs, even
> >> new third-party ufuncs that the duck array library has never heard of,
> >
> >
> > I see where you're going with this. You are thinking of reusing the
> ufunc implementation to do a computation. That's a minor use case (imho),
> and I can't remember seeing it used.
>
> I mean, I just looked at dask and xarray, and they're both doing
> exactly what I said, right now in shipping code. What use cases are
> you targeting here if you consider dask and xarray out-of-scope? :-)
>

I don't think that's the interesting part, or even right. When you call
`np.cos(dask_array_of_cupy_arrays)`, it certainly will not reuse the NumPy
ufunc np.cos. It will call da.cos, and that will in turn call cupy.cos. Yes
it will call np.cos if you feed it a dask array that contains a NumPy
ndarray under the hood. But that's equally true of np.mean, which is not a
ufunc. The story here is ~95% parallel for __array_ufunc__ and
__array_function__. When I said not seeing used, I meant in ways that are
fundamentally different between those two protocols.


> > this is case where knowing if something is a ufunc helps use a property
> of it. so there the more specialized nature of __array_ufunc__ helps. Seems
> niche though, and could probably also be done by checking if a function is
> an instance of np.ufunc via __array_function__
>
> Sparse arrays aren't very niche... and the isinstance trick is
> possible in some cases, but (a) it's relying on an undocumented
> implementation detail of __array_function__; according to
> __array_function__'s API contract, you could just as easily get passed
> the ufunc's __call__ method instead of the object itself,


That seems to be a matter of making it documented? Currently the dispatcher
is only attached to functions, not methods.

and (b) it
> doesn't work at all for ufunc methods like reduce, outer, accumulate.
>

No idea without looking in more detail if this can be made to work, but a
quick count in the SciPy code base says ~10 uses of .reduce, 2 of .outer
and 

Re: [Numpy-discussion] [JOB] Principal Software Engineer position at IHME

[Ralf Gommers]

On Mon, Sep 9, 2019 at 4:14 PM Chun-Wei Yuan  wrote:

> I see.  Sorry.  I think I misinterpreted "It is okay to post job ads for
> work involving NumPy/SciPy and related packages if you put [JOB] in the
> subject".  Thanks for the clarification.
>

That might be our fault for not updating that page, thanks for pointing
that out. That bit of text stems from a time when it was still quite
unusual to be able to use NumPy et al. in a job. Luckily these days that's
different;)

Cheers,
Ralf



>
> On Mon, Sep 9, 2019 at 3:19 PM Ralf Gommers 
> wrote:
>
>>
>>
>> On Mon, Sep 9, 2019 at 2:27 PM Chun-Wei Yuan 
>> wrote:
>>
>>> *The Institute for Health Metrics and Evaluation (IHME) *has an
>>> outstanding opportunity for a full-time *Principal Software Engineer *on
>>> our Forecasting/Future Health Scenarios (FHS) team*.* The development
>>> arm of the team is responsible for the design and implementation of
>>> software to support this effort, and the Principal Software Engineer will
>>> lead the development work and supervise engineers on that team. IHME’s aim
>>> within the FHS portfolio is to create an analytic engine that can model the
>>> impact of a wide array of determinants on the trajectory of health outcomes
>>> and risks in different countries, projected 25 years into the future, that
>>> will allow decision-makers to assess the impact of their potential actions
>>> analytically.  A recent publication can be found here:
>>> https://www.thelancet.com/journals/lancet/article/PIIS0140-6736(18)31694-5/fulltext
>>>
>>>
>>>
>>> If you join IHME, you’ll be joining a team of mission-oriented people
>>> who are committed to creating a welcoming and diverse workforce that
>>> respects and appreciates differences, and embraces collaboration.
>>>
>>>
>>>
>>> *Further Information: *See IHME’s website: www.healthdata.org
>>>
>>> *To Apply and see the whole job description: *Please apply at
>>> uw.edu/jobs
>>> 
>>>  and search for req 171527
>>>
>>>
>>> Please direct your questions to Megan at mkma...@uw.edu
>>>
>>
>> Hi Chun-Wei, while this seems like an interesting job, it's not clear
>> that it provides an opportunity to contribute back to NumPy or other
>> community projects (that'd be awesome though, and I would encourage you to
>> make that part of this job). For general software job ads (even if they use
>> NumPy), we'd prefer to keep those off this list.
>>
>> Thank you,
>> Ralf
>>
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] [JOB] Principal Software Engineer position at IHME

[Chun-Wei Yuan]

I see.  Sorry.  I think I misinterpreted "It is okay to post job ads for
work involving NumPy/SciPy and related packages if you put [JOB] in the
subject".  Thanks for the clarification.

On Mon, Sep 9, 2019 at 3:19 PM Ralf Gommers  wrote:

>
>
> On Mon, Sep 9, 2019 at 2:27 PM Chun-Wei Yuan 
> wrote:
>
>> *The Institute for Health Metrics and Evaluation (IHME) *has an
>> outstanding opportunity for a full-time *Principal Software Engineer *on
>> our Forecasting/Future Health Scenarios (FHS) team*.* The development
>> arm of the team is responsible for the design and implementation of
>> software to support this effort, and the Principal Software Engineer will
>> lead the development work and supervise engineers on that team. IHME’s aim
>> within the FHS portfolio is to create an analytic engine that can model the
>> impact of a wide array of determinants on the trajectory of health outcomes
>> and risks in different countries, projected 25 years into the future, that
>> will allow decision-makers to assess the impact of their potential actions
>> analytically.  A recent publication can be found here:
>> https://www.thelancet.com/journals/lancet/article/PIIS0140-6736(18)31694-5/fulltext
>>
>>
>>
>> If you join IHME, you’ll be joining a team of mission-oriented people who
>> are committed to creating a welcoming and diverse workforce that respects
>> and appreciates differences, and embraces collaboration.
>>
>>
>>
>> *Further Information: *See IHME’s website: www.healthdata.org
>>
>> *To Apply and see the whole job description: *Please apply at uw.edu/jobs
>> 
>>  and search for req 171527
>>
>>
>> Please direct your questions to Megan at mkma...@uw.edu
>>
>
> Hi Chun-Wei, while this seems like an interesting job, it's not clear that
> it provides an opportunity to contribute back to NumPy or other community
> projects (that'd be awesome though, and I would encourage you to make that
> part of this job). For general software job ads (even if they use NumPy),
> we'd prefer to keep those off this list.
>
> Thank you,
> Ralf
>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] [JOB] Principal Software Engineer position at IHME

[Ralf Gommers]

On Mon, Sep 9, 2019 at 2:27 PM Chun-Wei Yuan  wrote:

> *The Institute for Health Metrics and Evaluation (IHME) *has an
> outstanding opportunity for a full-time *Principal Software Engineer *on
> our Forecasting/Future Health Scenarios (FHS) team*.* The development arm
> of the team is responsible for the design and implementation of software to
> support this effort, and the Principal Software Engineer will lead the
> development work and supervise engineers on that team. IHME’s aim within
> the FHS portfolio is to create an analytic engine that can model the impact
> of a wide array of determinants on the trajectory of health outcomes and
> risks in different countries, projected 25 years into the future, that will
> allow decision-makers to assess the impact of their potential actions
> analytically.  A recent publication can be found here:
> https://www.thelancet.com/journals/lancet/article/PIIS0140-6736(18)31694-5/fulltext
>
>
>
> If you join IHME, you’ll be joining a team of mission-oriented people who
> are committed to creating a welcoming and diverse workforce that respects
> and appreciates differences, and embraces collaboration.
>
>
>
> *Further Information: *See IHME’s website: www.healthdata.org
>
> *To Apply and see the whole job description: *Please apply at uw.edu/jobs
> 
>  and search for req 171527
>
>
> Please direct your questions to Megan at mkma...@uw.edu
>

Hi Chun-Wei, while this seems like an interesting job, it's not clear that
it provides an opportunity to contribute back to NumPy or other community
projects (that'd be awesome though, and I would encourage you to make that
part of this job). For general software job ads (even if they use NumPy),
we'd prefer to keep those off this list.

Thank you,
Ralf
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] [JOB] Principal Software Engineer position at IHME

[Chun-Wei Yuan]

*The Institute for Health Metrics and Evaluation (IHME) *has an outstanding
opportunity for a full-time *Principal Software Engineer *on our
Forecasting/Future Health Scenarios (FHS) team*.* The development arm of
the team is responsible for the design and implementation of software to
support this effort, and the Principal Software Engineer will lead the
development work and supervise engineers on that team. IHME’s aim within
the FHS portfolio is to create an analytic engine that can model the impact
of a wide array of determinants on the trajectory of health outcomes and
risks in different countries, projected 25 years into the future, that will
allow decision-makers to assess the impact of their potential actions
analytically.  A recent publication can be found here:
https://www.thelancet.com/journals/lancet/article/PIIS0140-6736(18)31694-5/fulltext



If you join IHME, you’ll be joining a team of mission-oriented people who
are committed to creating a welcoming and diverse workforce that respects
and appreciates differences, and embraces collaboration.



*Further Information: *See IHME’s website: www.healthdata.org

*To Apply and see the whole job description: *Please apply at uw.edu/jobs

 and search for req 171527


Please direct your questions to Megan at mkma...@uw.edu
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] NEP 32: Remove the financial functions from NumPy

[D.S. McNeil]

[coming over from the pydata post]

I just checked about ~150KLOC of our Python code in a financial context,
written by about twenty developers over about four years.  Almost every
function uses numpy, sometimes directly and sometimes via pandas. 

It seems like these functions were never used anywhere, and the lead dev on
one of the projects responded "never used them; didn't even know they
exist".  I knew they existed, but even on the rare occasion I need the
functionality I need better control over the dates, which means for
practical purposes I need something which supports Series natively anyhow.

As it is, they also clutter up the namespace in unfriendly ways: if there's
going to be a top-level function called np.rate I don't think this is the
one it should be.  Admittedly that's more an argument against their current
location.

Although it wouldn't be useful for us, I could imagine someone finding a
package which provides numpy-compatible versions of the many OpenFormula (or
whatever the spec is called) functions helpful.  Having numpy carry a tiny
subset of them doesn't feel productive.

+1 for removing them. 


Doug



--
Sent from: http://numpy-discussion.10968.n7.nabble.com/
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] numpy C-API :: use numpy's random number generator in a ufunc

[Daniel Knüttel]

Hi folks,

I currently have a project that requires randomness in a ufunc. 
In order to keep the ufuncs as reproducible as possible I would like to
use numpy's random number generator for that; basically because setting
the seed will be more intuitive this way.

However I cannot find the documentation of the numpy.random C-API (does
it have one?). How would one do that?

Cheers,
-- 
Daniel Knüttel 

___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Using hypothesis in testing

[Matti Picus]

  
  
We have discussed using the hypothesis package to generate test
  cases at a few meetings informally. At the EuroSciPy sprint,
  kitchoi took up the challenge and issued a pull request
  https://github.com/numpy/numpy/pull/14440 that actually goes ahead
  and does it. While not finding any new failures, the round-trip
  testing of s = np.array2string(np.array(s)) shows what hypothesis
  can do. The new test runs for about 1/2 a second. In my mind the
  next step would be to use this style of testing to expose problems
  in the np.chararray routines.



What do you think? Is the cost of adding a new dependency worth
  the more thorough testing?
Matti

  

___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion