ok then - let's do this. Thanks a lot @kmuehlbauer

Nice! Unless @dcherian has any additional comments I'll merge in a few days

gentle ping @shoyer @dcherian I think this is not too far away

I had another look and seems fine to me. So let's ping @shoyer & @dcherian for a review.

Could you use signature.all_output_core_dims ?

You could go for something like this:

```python output_sizes_renamed = dict() for key, value in output_sizes.items():

if key not in signature.output_core_dims:
    raise ValueError("dimension name in 'output_sizes' must correspond to output_core_dims")
output_sizes_renamed[signature.dims_map[key]] = value

```

Instead of python output_sizes = { signature.dims_map[key]: value for key, value in output_sizes.items() }

Ok, yes I am happy with erroring ourselves.

Yes, I think this got lost in a resolved comment.

output_core_dims=[{"abc": 2}] looks very elegant. But it is passed to _UFuncSignature(input_core_dims, output_core_dims) so you would probably need to take it apart again in the code (or adapt _UFuncSignature to handle this case). Not sure how involved this is. Could potentially be left for a future PR?

Could be "Avoid adjusting gufunc’s meta dtype twice" in https://docs.dask.org/en/latest/changelog.html#id84

Not sure if it is better to xfail or bump the version of dask (which could be done ipython ci/min_deps_check.py ci/requirements/py36-min-all-deps.yml)

No need to worry about the second one:

https://github.com/pydata/xarray/blob/e5cc19cd8f8a69e0743f230f5bf51b7778a0ff96/xarray/core/computation.py#L704

output_dtypes: yes I think the docs should be updated

What I was trying to say - this is a change that can break existing code and it is not easy to do a proper deprecation cycle (i.e. only throw a warning). (I think allow_rechunk=True is not a good default.)

Ok an easier idea (could be brittle, though):

```python try: res = da.apply_gufunc(...)

catch error that was not raised in earlier versions of xr.apply_ufunc

except ValueError as e: if "with different chunksize present" in str(e): warnings.warn(str(e) + " This will throw an error in the future.") res = da.apply_gufunc(..., allow_rechunk=True) else: raise

``` However, I am only throwing around ideas - this is certainly not up to me. Let's see what the others think. Maybe they have an opinion or a better idea.

I don't see meta listed in the docs which is why it thought it's not needed. But if it is handled in dask.array.apply_gufunc it can of course stay.

I only realised the exact distinction between "allowed" and "parallelized" today - i.e. that "parallelized" is kind of the dask equivalent of np.vectorize. I can suggest something for the docstring (e.g. prefer "allowed" if ``func`` natively handles dask arrays or so)

Maybe this is too defensive/surprising, and could be relaxed.

You would remove the daks="forbidden" branch and not the dask="parallelized"?

For the functions that don't handle dask arrays gracefully, dask="parallelized" would be the better option?

Very cool - good progress.

• I guess you'll have to properly deprecate meta, something along the lines of: meta is no longer necessary and has no effect. it will be removed in a future version
• I think it would be good to pass allow_rechunk.

I'll only be able to look at it properly next week.

Should you keep the dask="allowed" branch? That might solve some of the issues (instead of using allow_rechunk=True) . For example dask has it's own einsum implementation (used in xr.dot) so it may not be necessary to pipe that through dask.array.apply_gufunc (from the docstring: this function is like np.vectorize, but for the blocks of dask arrays). However, I am only speculating.

Thanks! That would be quite cool!

dask.array.apply_gufunc does some fancy stuff with np.vectorize (to determine the output_dtypes) so I would not vectorize the function ourselves. For the other I don't have a qualified opinion.

Ah yes I see (https://github.com/pydata/xarray/issues/1815#issuecomment-440089606). dask.array.apply_gufunc should also be able to handle one output only.

A complete refactor of apply_ufunc would be quite some challenge.

Indeed - I think it could simplify _apply_blockwise (and might make the meta keword obsolete) but it would be good if someone with more experience of dask could weigh in.

@dcherian @shoyer

• It might be good to add a test with a reduction and one with vectorize=True.
• Would it be possible to replace the call to dask.array.blockwise (for one output variable) with dask.array.apply_gufunc? Do you know why blockwise is used further below and not dask.array.apply_gufunc? I assume it's due to historical reasons but I am not sure.
• dask.array.apply_gufunc does all sorts of stuff - e.g. infer meta. This could potentially solve #4015 (pull #4022) and simplify the call signature of apply_ufunc?

https://github.com/dask/dask/blob/3573b2ddca81aeb41a7def6dd4194020f853ab18/dask/array/gufunc.py#L175