issue_comments

hopefully out this week! I am going to wait another day or two for someone else to look at https://github.com/pydata/xarray/pull/3040/ and then will probably be issuing a release.

@shoyer Any idea when there might be another release of xarray where this fix will be included? I'm teaching a tutorial at SciPy this year that is effected by this bug. Learners are starting to prepare for the tutorials and I'd like if they could have this fix before the day of the tutorial.

@djhoese It looks like something broke in the development version of dask. But that shouldn't hold up merging your fix here...

@shoyer Makes sense. Any idea what's up with the travis test? It doesn't look like it is from my changes.

I'd be happy to merge this fix. I think it's a vestige of when we used to always cached computations.

I'd also love to have more comprehensive test coverage, and I like the look of your custom scheduler. But I'm not sure it's worth adding that many lines of test logic for what is essentially a one line fix.

In my own tests I've been using the following custom scheduler with dask.config.set(scheduler=CustomScheduler()) to point out what code is computing the array when I don't want it to:

``` class CustomScheduler(object): """Custom dask scheduler that raises an exception if dask is computed too many times."""

def __init__(self, max_computes=1):
    """Set starting and maximum compute counts."""
    self.max_computes = max_computes
    self.total_computes = 0

def __call__(self, dsk, keys, **kwargs):
    """Compute dask task and keep track of number of times we do so."""
    import dask
    self.total_computes += 1
    if self.total_computes > self.max_computes:
        raise RuntimeError("Too many dask computations were scheduled: {}".format(self.total_computes))
    return dask.get(dsk, keys, **kwargs)

```

Does something like this exist in the xarray tests? If not, I could add it then add a dask test to the DataArray tests.