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.

I just came along this question as I tried something similar to @joshburkart. Using a string-enum instead, the code works in principle:

```python import enum

import numpy as np import pandas as pd import xarray as xr

class CoordId(str, enum.Enum): LAT = 'lat' LON = 'lon'

pd.DataFrame({CoordId.LAT: [1,2,3]}).to_csv()

Returns: ',CoordId.LAT\n0,1\n1,2\n2,3\n'

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], )

output

<xarray.DataArray (lat: 3, lon: 2)>

array([[0, 1],

[2, 3],

[4, 5]])

Coordinates:

* lat (CoordId.LAT) int64 1 2 3

* lon (CoordId.LON) int64 7 8

```

We however got somewhat ambivalent results, that the dimensions are still enum elements dims = (<CoordId.LAT: 'lat'>, <CoordId.LON: 'lon'>), but the coordinate names are the strings. After writing and reading the DataArray, everything is a plain string, we can still access the elements using the enum elements, as they are equal to the strings.

Just to clarify @shoyer, you said (2) sounds best to you, but your other comments (e.g. duck typing, requiring hashable) seem to describe (1)...? Slightly confused...

Some options that come to mind:

1. Allow any object with a __str__ method to be supplied as a variable/dimension label, but then delegate all internal sorting/printing/etc. logic to str(label).
2. Just implicitly run str on everything a user tries to input as a label (both when creating an xarray object and when accessing fields from an existing object), so that only strings are used internally.
3. Put this on the user, and only allow calling xarray objects/methods/etc. with labels already strings, as you suggested @shoyer.

I dunno. Whatever the maintainers think is best? (3) seems least complex on the xarray side, but (1) or (2) might be more convenient for users.

Thanks @shoyer. I'll see if I can take a look in the near future...