issues

I did the easy things, but will need help for the final couple on _typed_ops.py

Because we don't pin mypy (should we?), this blocks other PRs if we gate them on mypy passing

• [ ] User visible changes (including notable bug fixes) are documented in whats-new.rst

Edit: I added a comment outlining a problem with this

I think we should be using a TypeVar(..., bound=...) for our typing, since otherwise subtypes aren't allowed. I don't see a compelling reason to have all of T_DataWithCoords and T_DataArrayOrSet and T_Xarray, though I might be missing something.

So this unifies all T_DataWithCoords, T_DataArrayOrSet and T_Xarray to T_Xarray, and changes that type to be bound on a union of DataArray & Dataset (similar to the existing T_DataArrayOrSet). This covers the bulk of our API — functions which transform either a DataArray or Dataset and return the input type.

This does require some manual casts; I think because when there's a concrete path for both DataArray & Dataset, mypy doesn't unify them back together. It's also possible I'm missing something.

One alternative — a minor change — would be to bound on DataWithCoords, like the existing T_DataWithCoords, rather than the union. A quick comparison showed each required some additional casts / ignores over the other.

• [x] From https://github.com/pydata/xarray/issues/7164
• [x] User visible changes (including notable bug fixes) are documented in whats-new.rst

I'm not confident about the CI change; either we can merge with the "this is a trial message" and see how it goes, or split that into a separate PR and discuss.

• [x] Closes #6391
• [x] Tests added
• [x] User visible changes (including notable bug fixes) are documented in whats-new.rst
• [x] New functions/methods are listed in api.rst

This probably needs a review and another turn, maybe some more tests on multiple objects etc. There are a couple of questions inline.

This replaces https://github.com/pydata/xarray/pull/5787.

Please check out the previews in the most recent comment there

Currently about 40% of the time is taken by installing things, hopefully we can cut that down

• [x] Tests added
• [x] User visible changes (including notable bug fixes) are documented in whats-new.rst

IIUC: - This test below would fail mypy because the key of Mapping is invariant (though Any still lets anything through) - I've only seen this when the dict is defined in a different expression from the Dataset constructor - Mypy doesn't type-check our test functions, because the functions don't have any annotations.

If that's correct, we should change all our Mapping to use Any rather than Hashable, and add type annotations to our test functions (even just -> None)

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

Please make suggestions for any changes!

• [x] Closes #3789
• [x] Passes isort -rc . && black . && mypy . && flake8
• [x] Fully documented, including whats-new.rst for all changes and api.rst for new API

After doing this, I realize it needs to wait until 0.16, assuming 0.15.1 is our next release. If so, this should hang out until then.

A few small tweaks, including a script for getting all recent contributors (feel free to edit if my bash is bad).

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

HT to @crusaderky for the idea!

The only other warning is:

```

xarray/tests/test_dataset.py::TestDataset::test_convert_dataframe_with_many_types_and_multiindex /Users/maximilian/workspace/xarray/xarray/core/dataset.py:3146: FutureWarning: Converting timezone-aware DatetimeArray to timezone-naive ndarray with 'datetime64[ns]' dtype. In the future, this will return an ndarray with 'object' dtype where each element is a 'pandas.Timestamp' with the correct 'tz'. To accept the future behavior, pass 'dtype=object'. To keep the old behavior, pass 'dtype="datetime64[ns]"'. data = np.asarray(series).reshape(shape) /usr/local/lib/python3.7/site-packages/pandas/core/apply.py:286: FutureWarning: Converting timezone-aware DatetimeArray to timezone-naive ndarray with 'datetime64[ns]' dtype. In the future, this will return an ndarray with 'object' dtype where each element is a 'pandas.Timestamp' with the correct 'tz'. To accept the future behavior, pass 'dtype=object'. To keep the old behavior, pass 'dtype="datetime64[ns]"'. results[i] = self.f(v) ```

I'm not sure what we want to do here - potentially we should make a choice between: - the worse behavior of object - accepting the coercing to naive datetimes - supporting pandas extension arrays

I was still getting stickler errors for code I hadn't changed. Flake8 should now pass

• [x] Closes #1651
• [x] Tests added / passed
• [ ] Passes git diff upstream/master **/*py | flake8 --diff
• [ ] Fully documented, including whats-new.rst for all changes and api.rst for new API

No docs / docstrings. No backfill.

But otherwise is this a reasonable layout? Do we prefer fillna with options (back / forward / replacement), or ffill, bfill, fillna?

A start for some docs on transitioning from pandas Panel to xarray.

This is some way from the final version - but putting it out there and will iterate.

Not sure if this was a deliberate choice (maybe so integer indexing wasn't disrupted?). This allows objects as dataset keys / labels.

Let me know your thoughts and I'll add a what's new.

(I know I have a few PRs dangling - apologies - will go back and clean them up soon)

Resolves the most pressing issue in #645