ds.coords.dims can display dims not present in the coordinate vars

[TomNicholas]

This (on main) looks wrong to me:

In [1]: import xarray as xr

In [2]: ds = xr.Dataset({'a': ('x', [0, 1])})

In [3]: ds
Out[3]: 
<xarray.Dataset> Size: 16B
Dimensions:  (x: 2)
Dimensions without coordinates: x
Data variables:
    a        (x) int64 16B 0 1

In [4]: ds.coords
Out[4]: 
Coordinates:
    *empty*

In [5]: ds.coords.dims
Out[5]: FrozenMappingWarningOnValuesAccess({'x': 2})

I mean the fact no-one has raised this before means it probably isn't of much consequence, but it does seem incorrect / misleading.

Originally posted by @TomNicholas in #9451 (comment)

The issue here being that the DatasetCoordinates object displays a dim with no associated variable.

I'm not sure whether anything about the concept of "virtual coordinate variables" affects this.

(The FrozenMappingWarningOnValuesAccess is just a Mapping, it's only weird due to the ongoing deprecation cycle started in #8500.)

[shoyer]

Dimensions part of coordinates, even if they aren't present on coordinate variables -- we need them for correct alignment.

So I think we should add them to the repr instead, ideally something like:

>>> ds.coords
<xarray.Coordinates>
Dimensions:   (x: 2)
Coordinates:
    *empty*

[TomNicholas]

we need them for correct alignment

Can you do xr.align on a ds.coords object?

Also note how similar this question is to #9463...

[shoyer]

Can you do xr.align on a ds.coords object?

Yes, it looks like this works, though I'm a little puzzled by how :)

[shoyer]

Regardless, you definitely need dims + coords (+ indexes) to do alignment. So it makes sense to display them in the Coordinates repr.

[benbovy]

Yes, it looks like this works, though I'm a little puzzled by how :)

This was implemented in #7368.

you definitely need dims + coords (+ indexes) to do alignment. So it makes sense to display them in the Coordinates repr.

Yes I agree we should display the dimensions in the Coordinates repr. However, ds.coords.dims still returns wrong results in the example above IMO. We have this inconsistent behavior:

>>> ds.coords.dims
FrozenMappingWarningOnValuesAccess({'x': 2})
>>> xr.Coordinates(ds.coords).dims
FrozenMappingWarningOnValuesAccess({})

ds.coords.dims returning an empty mapping as well would make more sense, especially if we plan for dataset/dataarray coordinates to move from proxy objects to "standalone" variable containers (#9203 (comment)).

[shoyer]

Yes I agree we should display the dimensions in the Coordinates repr. However, ds.coords.dims still returns wrong results in the example above IMO. We have this inconsistent behavior:

>>> ds.coords.dims
FrozenMappingWarningOnValuesAccess({'x': 2})
>>> xr.Coordinates(ds.coords).dims
FrozenMappingWarningOnValuesAccess({})

ds.coords.dims returning an empty mapping as well would make more sense, especially if we plan for dataset/dataarray coordinates to move from proxy objects to "standalone" variable containers (#9203 (comment)).

I agree these should absolutely be consistent. However, I would lean towards the opposite fix -- including the extra dimension in both cases!

[benbovy]

The opposite fix would be consistent as well if Coordinates objects were always proxies, but this isn't the case anymore. Returning different dimensions depending on whether a Coordinates object is a direct proxy ds.coords, a indirect proxy xr.Coordinates(ds.coords) or a "pure" standalone xr.Coordinates(dict(ds.coords)) object - all those (name, DataArray) mappings being equivalent - feels unnecessarily complicated to me.

>>> standalone_coords = xr.Coordinates(dict(ds.coords))
>>> standalone_coords.dims   # no extra dimension possible here!
FrozenMappingWarningOnValuesAccess({})

Should the checks below return False?

>>> standalone_coords.equals(ds.coords)
True
>>> standalone_coords.equals(xr.Coordinates(ds.coords))
True

[shoyer]

The opposite fix would be consistent as well if Coordinates objects were always proxies, but this isn't the case anymore. Returning different dimensions depending on whether a Coordinates object is a direct proxy ds.coords, a indirect proxy xr.Coordinates(ds.coords) or a "pure" standalone xr.Coordinates(dict(ds.coords)) object - all those (name, DataArray) mappings being equivalent - feels unnecessarily complicated to me.

Agreed! But then why not add dimension sizes into Coordinates? This would allow us to delegate to Coordinates for all alignment between Xarray objects.

[benbovy]

This would makes things easier indeed regarding (the implementation of) alignment!

I'm not sure whether or not it is a good idea to allow extra dimensions in a Coordinates object, though. Those dimensions might easily be seen as arbitrary and/or coming from nowhere, as opposed to the dimensions of a DataArray or a Dataset?

When passing around coordinates, e.g., ds.assign_coords(coords_obj), xr.Dataset(coords=coords_obj) or xr.Coordinates(coords_obj), it is not clear to me whether it is preferable to include or ignore those extra dimensions.

[shoyer]

When passing around coordinates, e.g., ds.assign_coords(coords_obj), xr.Dataset(coords=coords_obj) or xr.Coordinates(coords_obj), it is not clear to me whether it is preferable to include or ignore those extra dimensions.

In the context of an xarray data object (Dataset, DataArray or DataTree), I would keep the invariant that the data object's dimensions are the union of all those found on all contained Variable objects.

For assigning coordinates to a Dataset, this suggests:

1. If you assign coordinates with a superset of dimensions in the resulting Dataset, drop them. (Dimensions are recalculated from contained variables.)
2. If you assign coordinates with a subset of dimensions on a Dataset, this is OK. (Dimensions are recalculated from contained variables.)
3. If you assign coordinates with inconsistent dimensions to a Dataset, this should raise an error -- even if those dimensions are not associated on the Coordinates object with any variables.

For creating new coordinates like Coordinates(coords_obj) I would simply do a shallow-copy of the original coordinates.