issue_comments

The only obvious difference being that one overload annotates self, while the other doesn't. But apart from this, the annotations look straightforward (and correct) to me.

note that pylance says the same: Type of "result" is "Dataset | DataArray"

This is raised by matplotlib, not pandas. Personally, I prefer aligning with upstream projects, so I'd pick that very same error.

One could argue that it's a ValueError in the sense that there's no data to plot, which is like an invalid value. But I also could see why they picked TypeError, because one could have non-numeric (but not empty) data. But yeah, this is nitpicking, I suppose 😆

👁️ @headtr1ck

Iterables (implement __iter__) not only aren't ordered, but also neither have a length (implement __len__ nor allow for membership tests (implement __contains__). So in these cases one needs to use Sequences, too; in addition to cases where order matters.

See https://docs.python.org/3.9/library/collections.abc.html#collections-abstract-base-classes

Would like to chime in that we use a similar approach as in the last comment of @DerWeh . But we extend this by overloading the __str__ method of the enum.Enum base class, and implement a Dimension base class to use for our enum dimensions:

``` class Dimension(str, enum.Enum): """Base class for all dimension enums

It is of type string because this is needed for xarray.
"""

def __str__(self):
    return type(self).__name__ + "." + self.name

```

Using this the xarray output is more consistent:

```

class CoordId(Dimension): ... LAT = 'lat' ... LON = 'lon' ... xr.DataArray( ... data=np.arange(3 * 2).reshape(3, 2), ... coords={CoordId.LAT: [1, 2, 3], CoordId.LON: [7, 8]}, ... dims=[CoordId.LAT, CoordId.LON], ... ) <xarray.DataArray (CoordId.LAT: 3, CoordId.LON: 2)> array([[0, 1], [2, 3], [4, 5]]) Coordinates: * CoordId.LAT (CoordId.LAT) int64 1 2 3 * CoordId.LON (CoordId.LON) int64 7 8 ```

We then have deserialization code, that re-creates enum members when reading NetCDF files with corresponding dimensions (and coordinates). Access to coordinates works with enum members as well as their string value.

Yes, aux_1 (dim_1) should be split into chunks of two elements. At the same time, the coordinates aux_0 (dim_0) and * dim_0 (dim_0) should not be split at all. Even if it is not part of the API, it still is surprising that such DataArrays are created without warning or error. In other words, there isn't any check for self-consistency. I have to admit, though, that I'm not familiar with the internals of how xarray and numpy interact for these numpy array manipulation routines.

Thanks for asking this question to clarify! My example probably wasn't as concise as it could've been. In an attempt to improve here, I've shortened the example output a bit.

The issue isn't with the data variable content of the three split arrays, it's with the coordinates. It appears that coordinates along dim_0 have been split instead of those along dim_1. This leaves the resulting DataArrays malformed. Their coordinates do not match their corresponding dimensions in length.