Things to resolve for the v0.3 release

[pp-mo]

For now, listing issues here, rather than creating another project.
Since I think we are now very close 🤞 (!)

• merge dim_slicer
• merge subsequent docs improvements
• merge small fix to rename_dimension
• consider review project purpose descriptions

Then I think we can just review the release notes + make a release.

[pp-mo]

@trexfeathers @ukmo-ccbunney
Regarding the dim_slicer work, a new thought only just struck me about the "Slicer" syntax problem ...

So, I only just added the ability to not specify dimensions when indexing.
That is now an option for both the index_by_dimensions function and the Slicer -- they can just work with the top-level dimensions in given order.

It isn't directly connected, but it somehow made me think how much easier it might be to simply attach the slicing behaviour directly to the NcData objects.
You could then just..

>>> ncdata.index_dims
('Z', 'time', 'levels')
>>> region1 = ncdata[:3, 4:17]
>>> ncdata.index_dims = 'levels'
>>> ncdata.index_dims
('levels', 'Z', 'time')

Of course, I was trying to not add to the core object methods.
But all the same, did I miss an obvious simplification here?

Alternatively

Is it simpler to go back to only allowing a Slicer to use specifically-named dimensions?
That was the original idea.

UPDATE:

new thought, possibly nicer way.
Just supply in NcData:

  def slicer(self, *dim_names):
     return Slicer(self, dim_names)

Then we have..
data.slicer("x", "y")[7, 4:]
data.slice()[3:]

[ukmo-ccbunney]

@trexfeathers @ukmo-ccbunney Regarding the dim_slicer work, a new thought only just struck me about the "Slicer" syntax problem ...
...
It isn't directly connected, but it somehow made me think how much easier it might be to simply attach the slicing behaviour directly to the NcData objects. You could then just..
...
Of course, I was trying to not add to the core object methods. But all the same, did I miss an obvious simplification here?

Alternatively

Is it simpler to go back to only allowing a Slicer to use specifically-named dimensions? That was the original idea.

Hey @pp-mo .

So, I must admit that the first thing I tried (before reading any docs!) was to slice the actual NcData object as you proposed.

However, when I thought about this, it probably make more sense to do it via a convenience function or helper class as you have done so as this is more consistent with the behaviour of libraries such as xarray where subscripting the dataset accesses the variables, not performs slicing. Considering that ncdata is considered a sort of bridge between Iris and Xarray, maybe we would risk confusing users with inconsistent behaviour of slicing on dataset-like objects? I must admit it would be a much simpler way of slicing though!

Saying that, the Slicer class is neat and provides a nice "numpy" like slicing of the whole dataset. I wonder if it is worth also providing convenience methods on the actual NcData object to slice over dimensions, like Dataset.isel in xarray?

[trexfeathers]

Providing __getitem__ on NcData objects seems like the least-surprise approach. The sophisticated API you have provided has clear utility above __getitem__, but I naively would have called considered __getitem__ to be the MVP, with index_by_dimensions/Slicer being the bonus next steps.

[pp-mo]

OK, proposed API, from discussion with @ukmo-ccbunney ,

Support

data[3:, 7]
data.slicer()[3:, 7]  # (same as previous)
data.slicer("x", "y")[3:, 7]

But not ...

data.slicer("x", "y")[3:, 7, 4, 5]  # too many keys for dims
index_by_dimensions(data, 2, 3, x=4)  # mixed approach -- now supports only **kwargs, not *args
Slicer(data, "x")[2,3]  # too many dims

---

Additional changes:

• amend Slicer init to change the single dim_names arg to a *args ((as assumed above)).
  so Slicer(data, ["x", "y"]) --> Slicer(data, "x", "y")
• allow Slicer with no dimensions
  • so, Slicer(data) === Slicer(data, list(data.dimensions))
  • ... but not a mixture, i.e. len(keys) <= len(dim_names)