Dataset constructor always coerces 1D data variables with same name as dim to coordinates about xarray HOT 10 OPEN

what we could do is split the behavior between keyword-argument data_vars and positional argument number 1:

def __init__(self, vars=None, /, coords=None, attrs=None, *, data_vars=None):
    ...

where vars promotes to coordinates, but data_vars doesn't (and you can't pass vars and data_vars at the same time).

Then, at some point, we deprecate the positional argument or all positionals (not sure how that part should look like exactly, though).

from xarray.

what we could do is split the behavior between keyword-argument data_vars and positional argument number 1:

def __init__(self, vars=None, /, coords=None, attrs=None, *, data_vars=None):
    ...

where vars promotes to coordinates, but data_vars doesn't (and you can't pass vars and data_vars at the same time).

I like this idea. It makes the current behavior more explicit and makes it clear how to opt-in to the new behavior.

from xarray.

I think that comes explicitly from netCDF User's Guide and the CF Conventions("coordinate varible")

Though reading now, I guess it's saying all coordinate variables must be 1D with the same name as the dim, not necessarily the converse.

from xarray.

Auto-promoting dimension data variables as dimension coordinates when creating a new Dataset has been indeed the expected behavior so far.

I'm not sure what best we should do, though. On one hand, xr.Dataset(data_vars={"x": [0]}) creating a "x" coordinate looks definitely odd to me too. On the other hand, xr.Dataset({"x": [0]}) not creating a dimension coordinate would feel quite disruptive to me.

from xarray.

Thanks for that context @dopplershift !

The way I see it there are two consistent behaviours:

1. all variables that are 1D with the same name as the dim must be coordinate variables, and both Dataset.__init__ and .expand_dims() should therefore coerce data variables to coordinate variables if necessary,
2. variables that are 1D with the same name as the dim do not have to be coordinate variables, and we shouldn't coerce anywhere

On the other hand, xr.Dataset({"x": [0]}) not creating a dimension coordinate would feel quite disruptive to me.

Yeah this would break quite a lot of user code...

from xarray.

On the other hand, xr.Dataset({"x": [0]}) not creating a dimension coordinate would feel quite disruptive to me.

Is it possible to imagine a deprecation cycle for this? One which detects this input pattern and raises a warning telling you to use xr.Dataset(coords={"x": [0]}) instead?

from xarray.

That looks like a nice solution @keewis, except maybe xr.Dataset(data_vars={"x": [0]}) not creating an "x" coordinate, which would be a breaking change (in theory) and which would require another deprecation cycle?

from xarray.

true. But I guess people passing data_vars explicitly would be less likely to expect creating a coordinate variable from it, so we could shorten the cycle a bit (like, warn for 2-3 releases then switch to the new behavior).

from xarray.

We decided to start by raising PendingDeprecationWarning to slowly discourage this usage.

from xarray.

#8979 implements this suggestion. The same PendingDeprecationWarning is issued if a variable passed to data_vars is auto-promoted to a coordinate. Eventually we would have to break that auto-promotion and remove the vars positional-only argument to complete the deprecation cycle.

from xarray.