Implement `gufunc(pyfunc, ...)` similar to `numpy.vectorize` but without the vectorize part

This issue was suggested in dask/dask#3109

My current understanding is that numpy.vectorize provides a way to

1. provide a Python function,
2. assign it a signature with information about core dimensions,
3. bind it input data, where two things happen
   • call __array__ufunc__, if present, and/or
   • broadcast loop dimensions (according to signature) of input arrays against each other.
4. Iterative calls of the Python function over all loop dimension entries

I would like to suggest to implement an additional wrapper, just like numpy.vectorize, which does all the steps above, except step 4). I.e. a Python function could be wrapped as gufunc and given a signature, and when binding input the same Step 3) is applied.

The benefit is, that same data binding methodology and interface is used, if the user already provides a vectorized implementation of Python function. It becomes especially important for interoperability with other libraries, e.g. dask.

[mrocklin]

As a concrete example consider Scikit-Learn’s Estimator.predict method. This typically takes an n x m shaped array and produces an n shaped array, but it generally just broadcasts along the first dimension so it’s signature is probably something like (m)->()

It would be useful for Scikit-Learn to have some mechanism to be able to say “this function can be broadcast in the following way” and defer to objects that can do that sort of broadcasting (using the __array_ufunc__ protocol) when they are provided as inputs.

Concretely, it would be nice for downstream projects to be able to say the following:

class Estimator:
    @numpy.broadcastable('(m)->()')
    def predict(self, X):
        ...
        return y

Ideally then if a user provides something like a dask array

estimator = Estimator(...)
estimator.fit(...)

estimator.predict(my_dask_array)

Then ideally the decorated predict method would go through the normal checks for __array_ufunc__ and give control over to the dask array object.

[mattip]

If we design such a wrapper it should handle these better than the current gufunc mechanism:

• memory overlap requirements and temporary output buffer allocation
• specifying requirements for contiguous memory layout