API review for version 4.0.0: thoughts, ideas, linked Issues, etc.

[sadielbartholomew]

This Issue is to collate and register any comments (thoughts, ideas, tentative decisions, questions, etc.) including links to self-contained related Issues, regarding the cf-python API (and perhaps the API of cfdm too, also keeping cf-plot and it's eventual incorporation into cf-python in mind).

The context, for those unaware, is that we will be reviewing and revising the API for a forthcoming version 4.0.0, which we hope to release by the end of 2024. Anything anyone wants to register on the topic of the cf-python API is very welcome! Brain dumps are welcome, though we may want to move distinct topics to their own Issues and link them in, if themes emerge.

Useful references are:

• the Python Array API Standard, which we want to abide by unless there is good reason not to;
• the NumPy API which is of high relevance for our array-related operations;
• the Dask API ditto;
• the CF xarray API might be useful for background/comparison.

---

Please try to organise points/discussion as we go along into topics and themes, noting them below (ideally linking to comments and/or Issues). Anyone contributing to the thread feel free to edit/update this.

Topics and themes

• conforming to the Python Array API standard (see link above)
• deprecated objects:
  • ensure all deprecation errors include stating replacements, else messages to indicate why there isn't one any longer (etc.) - should only be a small number of cases that don't abide by this already.
• views/representations of fields/datasets:
  • including identical data in different formats, Unexpected behaviour comparing two views of the same data: pp and netcdf #775.
  • truncation for long FieldLists, arrays, etc., Configurably truncated representation when FieldList is very long #772.
• (methods for) conversion to/from other formats:
  • xarray, Converting field(s) to & from CF-compliant xarray.Dataset #773
• availability of methods on given objects vs. module-level, Provide cf.<method>(a, b) as wrapper to a.<method>(b) #277
• level of support for NumPy-like operations (generalising sentiment in Support selected new numpy-consistent Data methods #328)
  • more binary operations (now we are well-daskified), Support binary operations e.g. arctan2 division #38
• ensuring sets of related methods have full coverage, esp. pairs e.g. minima and maxima such as argmax and argmin (see Refactor for argmax and new method argmin #135)
• aliases e.g. for longer method names - when to use, what to use and how to document (including should we have a big table listing these?)
• simplifications in general - what can sensibly be streamlined?
• verbosity and logging (e.g. which methods deserve a verbose keyword)
  • getting all outputs managed under the logging umbrella, Subsume ESMF regrid logging configuration under log level #286.

[sadielbartholomew]

I have created the 'API review (4.0.0)' label and will tag anything relevant with it, encouraging others to do the same.

[sadielbartholomew]

As a general thought, we should probably have a separate issue to cover documentation (esp. API reference) improvement/overhaul, since existing methods, classes etc. with documentation we want to improve is related to, but not in scope for, API review, in my opinion.