Hi Martin,
It is. The point of the proposed feature was to handle array generation
mechanisms, that don't take an array as input in the standard NumPy API.
Giving them a reference handles both the dispatch and the decision about
which implementation to call.
I'm confused: Isn't your reference arr
On 28/06/18 17:18, Stephan Hoyer wrote:
On Thu, Jun 28, 2018 at 1:12 PM Marten van Kerkwijk
mailto:m.h.vankerkw...@gmail.com>> wrote:
For C classes like the ufuncs, it seems `__self__` is defined for
methods as well (at least, `np.add.reduce.__self__` gives
`np.add`), but not a `
Another option would be to directly compare the methods against known ones:
obj = func.__self__
if isinstance(obj, np.ufunc):
if func is obj.reduce:
got_reduction()
Eric
On Thu, 28 Jun 2018 at 17:19 Stephan Hoyer wrote:
> On Thu, Jun 28, 2018 at 1:12 PM Marten van Kerkwijk <
> m.
On Thu, Jun 28, 2018 at 1:12 PM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> For C classes like the ufuncs, it seems `__self__` is defined for methods
> as well (at least, `np.add.reduce.__self__` gives `np.add`), but not a
> `__func__`. There is a `__name__` (="reduce"), though, whic
> I did a little more digging, and turned up the __self__ and __func__
> attributes of bound methods:
> https://stackoverflow.com/questions/4679592/how-to-find-
> instance-of-a-bound-method-in-python
>
> So we might need another decorator function, but it seems that the current
> interface would ac
On Wed, Jun 27, 2018 at 12:50 PM Stephan Hoyer wrote:
> One concern this does raise is how to handle methods like those on
> RandomState, even though methods like random_like() don't currently exist.
> Distribution objects from scipy.stats could have similar use cases.
>
> So perhaps it's worth "
I think the usefulness of this feature is actually needed. Consider
`np.random.RandomState`. If we were to add what I proposed, the two could
work very nicely to (for example) do things like creating Dask random
arrays, from RandomState objects.
For reproducibility, Dask could generate multiple Ra
On Wed, Jun 27, 2018 at 3:50 PM, Stephan Hoyer wrote:
> So perhaps it's worth "future proofing" the interface by passing `obj` and
> `method` to __array_function__ rather than only `func`. It is slower to
> call a func via func.__call__ than func, but only very marginally (~100 ns
> in my tes
