Makes sense to me.

Can I nudge you to consider bumping xarrays minimum required version to 1.13 though? :-)

Can I nudge you to consider bumping xarrays minimum required version to 1.13 though? :-)

This might actually be a better idea. These days, upgrading numpy is easier than ever :). So after some contemplation, I'm no longer convinced this is essential.

It also occurs to me that many existing projects will just add a __array_ufunc__ method without adjusting their special operator overloads, and that's probably OK. (Even though many/most existing special method implementations are broken in various subtle ways, in practice that isn't a big deal.)

@mrocklin would you find such a mixin useful for dask?

@mrocklin would you find such a mixin useful for dask?

What reusable logic would this mixin have? I think that the competition to this idea is just to rebuild this logic each time in each codebase. Hopefully this logic isn't that complex. I haven't yet looked at the full spec though so I don't know if this is overly naive.

My initial inclination (again without heavy research) would be to build the __array_ufunc__ method in one project first (likely xarray is my guess) and then use that as an example for other projects to copy. If we find that we're rebuilding almost exactly the same code then we would choose to coordinate on an external package. I think that you have a deeper understanding of __array_ufunc__ than I do though.

What reusable logic would this mixin have?

Mostly this is pretty routine: defining every special operator in terms of it's matching numpy ufunc: https://github.com/numpy/numpy/blob/master/numpy/lib/mixins.py

My initial inclination (again without heavy research) would be to build the array_ufunc method in one project first (likely xarray is my guess) and then use that as an example for other projects to copy.

Sounds good. We'll probably defer for this now, then.

@mrocklin: it's mostly that the logic is a bit tiresome (defining all the binop special methods), has a few gotchas if you want to correctly interoperate with arbitrary third-party classes, and is exactly the same for every object that wants to quack like an ndarray, so it makes sense to have a standard implementation everyone shares. But the standard implementation that ships with numpy assumes that you have a recent numpy (both to have the mixin, and because that implementation assumes that it's being used with a numpy that supports __array_ufunc__). So @shoyer has been wondering if we should make another version that does something slightly-wrong-but-not-too-wrong and that works with older numpys. Anyway it sounds like you have a plan but that's what the question was :-)

OK, if there is a great deal of boiler plate then yes, I'd probably appreciate having it around.

I guess my general answer is "I'm not able to answer this without better understanding the costs."

I never got around to this and at this point it isn't worth the trouble -- NumPy 1.13 was released almost 5 years ago!