OK, let's get this in. @deanpospisil thanks for your contribution!

@jhamman I'm thinking it's probably worth issuing a 0.7.2 release shortly so we can get dot and rolling out into the wild?

I made two very minor suggestions for improvement inline, but I think the code here looks ready!

The only thing we need at now is hook up the documentation! Please add dot to api.rst and a release note in whats-new.rst.

I'm pleased to see how this is coming along. No need to apologize for the delay -- this stuff takes time and practice to figure out :).

I'd like to see more test cases so we can be confident this works properly. At the very least, we should test a dot product with multiple dimensions in common. Other edge cases worth checking: - all dimensions in common (e.g., dot product of an array with itself) - no dimensions in common (this should give a sensible error message -- does it?) - dot product with a scalar DataArray (should also error) - dot product with a Dataset (verify that this raises NotImplementedError using self.assertRaises or self.assertRaisesRegexp) - dot product with a numpy array (this should also error)

In generally, it's hard to have too many tests. One indication that you may not have enough tests comes from the "coveralls" status check, which you can find if you click on "Show all checks" at the bottom of the PR. Ideally, each PR should only increase, not decrease code coverage -- the idea is that unit tests should run over every possible code pathway.

You'll need to squash these into one commit (git rebase -i) and then rebase on master to fix what's new. See here for more details: http://pandas.pydata.org/pandas-docs/stable/contributing.html#combining-commits

I recommend running a tool like PEP8 to check the style here: https://pypi.python.org/pypi/pep8

a few more comments forthcoming, generally looks very good, though

Take a look at PEP8 guidelines on spaces -- you are inserting a few extras around your parentheses :)

In the dask test I'm having a little trouble with: self.assertLazyAndAllClose(eager, lazy) working with the DataArrays I make. Does it only take transformations of: self.eager_array self.lazy_array

Nope, it can handle any eager (numpy) and lazy (dask) xarray objects. Something like this should work:

```

depending on exactly what syntax we support

eager = self.eager_array.tensordot(self.eager_array[0]) lazy = self.lazy_array.tensordot(self.lazy_array[0])) self.assertLazyAndAllClose(eager, lazy) ```

The default (when no dims arg is given) should be to tensordot over all shared dims between DataArrays. And it should prevent you from not summing over all shared dims, since that will return a DataArray with repeated labels. I think it would be rare for people to want to tensor dot over different dimensions.

This is a good point! Arrays with redundant dimensions are not very useful.

The sane thing to do is to broadcast over dimensions that aren't being summed einsum style (e.g., like i in einsum('ij,ij->i', x, y)). This is similar to the way that @/np.matmul works.

That said, this is difficult to implement with numpy's dot/tensordot, so perhaps it's better to simply error or omit the dims argument entirely for now. Eventually, we might be able to do this using @/np.matmul (only in numpy 1.10 and newer).

I also wonder if perhaps we should rename this from tensordot to simply dot. I don't think we would want to use dot for anything else, and it might also be nice to support @ syntax as an alias for this in Python 3 (again, at some later point).

The test is failing because we don't have dask installed in all builds -- because dask is an optional dependency, and we want to make things still work when you don't have it installed.

We do have tests setup to skip if dask is not installed, by using the @requires_dask decorator. In this case, I would recommend moving the dask-specific tests to one of the existing test classes we've set up in test_dask.py. Take a look at this test case for an example of what this could look like: https://github.com/pydata/xarray/blob/v0.7.0/xarray/test/test_dask.py#L264-L267

I'll just note that one other logical way to do this would be to implement tensordot as an xray.Variable method, and implement DataArray.tensordot in terms of it. This is a little closer to how we've written existing methods in xarray. It would probably help eventually for if/when we implement this on Dataset (by consolidating code) but it's not really necessary now.

This also needs docs, minimally including a note in what's new (for v0.7.1), a docstring and a reference in the API docs.