What is your issue?

Any ideas what could be causing these? I can't immediately reproduce locally.

https://github.com/pydata/xarray/actions/runs/7105414268/job/19342564583

``` Error: TestDataArray.test_computation_objects[int64-method_groupby_bins-data]

AssertionError: Left and right DataArray objects are not close

Differing values: L <Quantity([[ nan nan 1. 1. ] [2. 2. 3. 3. ] [4. 4. 5. 5. ] [6. 6. 7. 7. ] [8. 8. 9. 9.333333]], 'meter')> R <Quantity([[0. 0. 1. 1. ] [2. 2. 3. 3. ] [4. 4. 5. 5. ] [6. 6. 7. 7. ] [8. 8. 9. 9.333333]], 'meter')> ```

This disallows redundant casts

FWIW I thought we had gone through many of the tests and forced them to have typed defs, maybe with the intention of turning on some elements of strict mode. But then I don't think we have any strictness checks at the moment, and I see many functions in the tests which don't have typing. Am I mis-rembering?? Or maybe we started but didn't get far enough (it is a big project...)

This may be overly prescriptive. We've had a number of recent issues which aren't minimal and link to external data, and then these languish on the Issue Tracker unanswered. That's a loss of time for all involved — the reporter of the issue as well as the maintainers.

To the extent we can predict which issues will languish, it would be better to give that guidance up front, and encourage examples which are easier to engage with. So this introduces a checklist that people need to proactively fill out.

• [x] Tests added
• [x] Passes isort . && black . && mypy . && flake8
• [x] User visible changes (including notable bug fixes) are documented in whats-new.rst

Inspired by @mathause research in https://github.com/pydata/xarray/issues/4571#issuecomment-724848270

Note that one test is removed: https://github.com/pydata/xarray/compare/master...max-sixty:sorted-keys?expand=1#diff-2db7f6624707083db4aaab1b62eb11352200ec9d3ac1055de84877912226d7b5L560

While I'm keen on simplifying the data structures, this may have some unforeseen consequences, and at least deserves some thought re how we handle differently ordered dims.

Currently this PR retains the sorting in reprs.

Any other changes?

I was doing some profiling on isel, and see there are some properties that (I think) never change, but are called frequently. Should we cache these on their object?

Pandas uses cache_readonly for these cases.

Here's a case: we call LazilyOuterIndexedArray.shape frequently when doing a simple indexing operation. Each call takes ~150µs. An attribute lookup on a python object takes ~50ns (i.e. 3000x faster). IIUC the result on that property should never change.

I don't think this is the solution to performance issues, and there's some additional complexity. Could they be easy & small wins, though?

• [x] Helps https://github.com/pydata/xarray/issues/1251
• [x] Tests added
• [x] Passes black . && mypy . && flake8
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API

This is the first step towards organizing these functions a bit better, as outlined in https://github.com/pydata/xarray/issues/1251, https://github.com/pydata/xarray/issues/1618, https://github.com/pydata/xarray/pull/2674

While this one is a fairly easy decision, others are going to be harder. Open to a more methodical up-front process before we start making changes, if we think that's necessary.

Some more warnings silenced

Not sure why these weren't picked up in some of the previous python3-ifying

• [x] Closes https://github.com/pydata/xarray/issues/1053
• [x] Tests added
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API

Is it really this easy? What am I missing?

I think with np.flip and bn.push, this should be simple. They're both fairly new and so would require version checks / upgrading the minimums.

One small issue, I wonder if anyone has come across this: bottleneck returns the numpy array rather than the DataArray - is that because it's not operating with the correct numpy interface?

Forward fill: array.values = bn.push(array.values, axis=array.get_axis_num(axis_name))

Backfill: ``` axis = array.get_axis_num(axis_name)

reverse for bfill

array = np.flip(array, axis=axis)

fill

array.values = bn.push(array.values, axis=axis)

reverse back to original

result = np.flip(scaling, axis=date_axis) ```

This looks like it's available with dir / tab complete, but actually isn't:

``` python In [13]: xr.DataArray(np.random.rand(10,3)).to_dataset('dim_1').rolling

AttributeError Traceback (most recent call last) <ipython-input-13-438d3638a0d0> in <module>() ----> 1 xr.DataArray(np.random.rand(10,3)).to_dataset('dim_1').rolling

/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/xarray/core/common.py in getattr(self, name) 135 return source[name] 136 raise AttributeError("%r object has no attribute %r" % --> 137 (type(self).name, name)) 138 139 def setattr(self, name, value):

AttributeError: 'Dataset' object has no attribute 'rolling' ```

I think this could be easy to implement as an .apply operation? (indeed, that could be a reasonable path for a whole host of operations - i.e. try and apply them to each array in the ds?)

Also, as a very narrow point, I'm not sure why .rolling_cls is public? Probably should be private?

Finally, the Rolling implementation is pretty sweet. I've been getting my hands dirty in the pandas one recently, and that we can have something as well featured as that with so few lines of code 👍

This is very peculiar & specific, but also fairly impactful for us.

If you - Create a Dataset with a coord that is a PeriodIndex - Transpose that coord - Add a variable to the Dataset that needs to be reindexed

...then the type of the index changes from object to int64. This then causes other arrays added to that dataset to show up as NaNs throughout.

Here's an example. Note the dtype('O')) at the end of each output.

``` python In [61]: series = pd.Series(np.random.rand(10),index=pd.period_range(start='2000', periods=10,name='date')) ​ ds = xray.Dataset({'number 1':series}) ds['number 2'] = ds['number 1'] ds, ds.date.dtype Out[61]: (<xray.Dataset> Dimensions: (date: 10) Coordinates: * date (date) object 10957 10958 10959 10960 10961 10962 10963 10964 ... Data variables: number 1 (date) float64 0.1133 0.5952 0.5467 0.2035 0.2022 0.6723 ... number 2 (date) float64 0.1133 0.5952 0.5467 0.2035 0.2022 0.6723 ..., dtype('O')) In [62]:

ds, ds.date.dtype ds=ds.transpose('date') ds, ds.date.dtype Out[62]: (<xray.Dataset> Dimensions: (date: 10) Coordinates: * date (date) object 10957 10958 10959 10960 10961 10962 10963 10964 ... Data variables: number 1 (date) float64 0.1133 0.5952 0.5467 0.2035 0.2022 0.6723 ... number 2 (date) float64 0.1133 0.5952 0.5467 0.2035 0.2022 0.6723 ..., dtype('O')) In [63]:

ds ds['number 3'] = ds['number 1'] ds, ds.date.dtype Out[63]: (<xray.Dataset> Dimensions: (date: 10) Coordinates: * date (date) object 10957 10958 10959 10960 10961 10962 10963 10964 ... Data variables: number 1 (date) float64 0.1133 0.5952 0.5467 0.2035 0.2022 0.6723 ... number 2 (date) float64 0.1133 0.5952 0.5467 0.2035 0.2022 0.6723 ... number 3 (date) float64 0.1133 0.5952 0.5467 0.2035 0.2022 0.6723 ..., dtype('O')) In [64]:

ds ds['number 4'] = ds['number 1'][:5] ds, ds.date.dtype Out[64]: (<xray.Dataset> Dimensions: (date: 10) Coordinates: * date (date) int64 10957 10958 10959 10960 10961 10962 10963 10964 ... Data variables: number 1 (date) float64 0.1133 0.5952 0.5467 0.2035 0.2022 0.6723 ... number 2 (date) float64 0.1133 0.5952 0.5467 0.2035 0.2022 0.6723 ... number 3 (date) float64 0.1133 0.5952 0.5467 0.2035 0.2022 0.6723 ... number 4 (date) float64 0.1133 0.5952 0.5467 0.2035 0.2022 nan nan nan ..., dtype('int64')) ```