issue_comments

Note that inferring dimensions from coords when it is a list of tuples does still work (with no deprecation warning): ``` In [1]: import numpy as np, xarray as xr

In [2]: xr.DataArray(np.zeros((2, 2)), coords=[('x', [1, 2]), ('y', [1, 2])])
Out[2]: <xarray.DataArray (x: 2, y: 2)> array([[0., 0.], [0., 0.]]) Coordinates: * x (x) int64 1 2 * y (y) int64 1 2 ```

Waiting a few more months until it will definitely not be a problem for anyone seems fair to me :+1:

I definitely agree it's better if possible. I think the tradeoff is between better for almost everyone vs the potential of a break for a small minority.

Currently we support python versions for 42 months, and Python 3.6 was released December 2016. So that means we support it until July 2020 -- given that timeframe I think we wait until then and add this back?

I think that inferring dimension-names from the coords-dict is the most intuitive way to define a DataArray.

Passing a dictionary for coords is in my opinion the clearest way to indicate which coordinates belong to which dimension, so then why do I have to specify the same dimension names again?

An example of how I create them from my current project: values = xr.DataArray( values, coords={'n_high': n_highs, 'n_low': n_lows, 'rep': repetitions, 'model': models, 'idx': range(n_test_samples),}, dims=['n_high', 'n_low', 'rep', 'model', 'idx'], <-- repeated dim names attrs=attributes, )

If you expect almost everyone to use CPython or 3.7+ anyway, then I don't actually see any drawbacks, while it would regularly make code shorter and less repetitive.

I guess it's still too soon to 'un-deprecate' this behavior again?

Ha! We do support 3.6. I think that almost everyone is using xarray with CPython, so it's almost certainly safe. But maybe not worth the tradeoff given the benefit is marginal, what are your thoughts?

@max-sixty Thanks for the tip. In the end it meant just changing the last line on dims. The paragraph on the coords argument is still valid after all.

On a related note: according to #727 (PR #993), this was deprecated since key-order in dictionaries was arbitrary at the time of that issue. However, their order is fixed since Python3.7, as noted in the documentation:

Changed in version 3.7: Dictionary order is guaranteed to be insertion order. This behavior was an implementation detail of CPython from 3.6.

I guess it's still too soon to 'un-deprecate' this behavior again? 👼

For the PR: in general we don't need to document deprecated behavior, so you can remove than description rather than caveat it

Agree! Thanks for spotting @sjvrijn . PR is appreciated, thanks for the offer!