Introduction of Dask for all data manipulations

[davidhassell]

Fixes #317

Implements Dask for all storage underlying cfdm.Data objects, by porting the corresponding code from cf-python.

Aims to not change the API, other than as required for the new functionality.

[davidhassell]

Note that the new cfdm/data/data.py has almost nothing in common with its predecessor!

[sadielbartholomew]

I am satisfied the functionality is all good here, and is preserved and inherited fine downstream in cf-python when using both this branch and the corresponding branch with removal from cf, NCAS-CMS/cf-python#836.

As usual I've raised some minor comments, mostly where docstrings explicitly reference the cf module which needs updating to {{package}} (else cfdm) now.

I was surprised we didn't need any packaging updates, but I double-checked and it seems we already added dask as a dependency to cfdm so that's sorted, and from running the command python -c "from setuptools import find_packages; from pprint import pprint; pprint(find_packages())" it looks like, despite many new data modules including a new __init__.py, there is nothing to add or remove from the setup.py packages key, so the setup.py doesn't need updating, as you likely determined yourself.

Overall all good, so once you've considered the minor comments in-line, feel free to merge. (Note I've been reviewing NCAS-CMS/cf-python#836 in cross-reference but still have some further checks to do on that side, so will submit the review for that shortly but not right away.)

[sadielbartholomew]

Thanks for addressing the (very) minor feedback items. Did a final sanity check and everything's good so feel free to merge (or I'll be doing the final review on the corresponding cf-python PR later today if you want to wait on that to merge them together).

[davidhassell]

Great - thanks, Sadie!

I'll hold off merging until the corresponding cf-python PR is also ready to merge, in case anything arising over there implies a change over here.

[davidhassell]

Following on from our off-line discussion on Data._binary_operation being a @classmethod, it occurs to me that we only need to comment on this in cfdm, and not also in cf-python, because cf-python is merely calling overloading it from an external library. Does that make sense?

    @classmethod
    def _binary_operation(cls, data, other, method):
        """Binary arithmetic and comparison operations.
        <snip>
        """
        # Note: This method is a classmethod to allow it's
        #       functionality to be used with a LHS operand that is
        #       not 'self'. This is not currently needed here, but
        #       could be useful in subclasses which overload this
        #       method, yet still want to access the parent method
        #       functionality via `super`. For instance, cf-python's
        #       `cf.Data._binary_operation` sometimes needs to apply
        #       the binary operation to a modified copy of its 'self'.
        inplace = method[2] == "i"

[sadielbartholomew]

Does that make sense?

Does to me! Thanks, all good with that.

[davidhassell]

Great. I'll add it in ...

[sadielbartholomew]

Thanks for addressing and discussing my concerns from the cf-python PR. I am happy with the explanatory comment here (one typo). Please merge (both PRs) once you feel ready!

[davidhassell]

Merging - thanks for the review, Sadie!