issue_comments

Here's my current thinking on implementation: - [x] Dataset._coords_keys is a set that keeps track of the names of variables that are coordinates. This would let us implement Dataset.coords as a dict-like object with very little overhead for lookups. - [x] DataArray.dataset should go away from the public AP (use to_dataset() instead); more importantly, DataArray objects should only know about their coordinates, not any other aspects of the underlying dataset (it's a leaky abstraction). - [x] Dataset.__iter__ only only iterate over non-coordinates; but __contains__ and __getitem__ should be unchanged. - [x] Of course, we should automatically save and load coordinates according to CF conventions.

Also, we need some new methods to make this workable (modeled off of pandas's set_index and reset_index): - [x] Dataset.set_coords(keys, inplace=False) turns the variables in names into coordinates - [x] Dataset.reset_coords(keys=None, drop=False, inplace=False) removes all coordinates and turns them back into variables (unless drop=True). - [x] DataArray.reset_coords() would be very similar to the dataset method; it would return a Dataset unless unless drop=True (in which case it would return another DataArray). - [ ] set_index(keys, inplace=False) should be both a DataArray and Dataset method.

An important aspect is that using non-index coordinates (a power user feature) should be optional, just like how using and understanding Dataset objects should be optional.

Still a few items to check off (see the open associated issues) but I don't think they are blockers to v0.3.

Some further thinking suggests that we can allow for multi-dimensional coordinates, but the only sane way to handle conflicting non-index coordinates is to drop them. Even Iris, with its strict interpretation of CF conventions, takes this approach.

Raising an exception for conflicting non-scalar variables would make multi-dimensional coordinates impractical.