`ordered` errors for all but cell method constructs

[ncas-cms]

`ordered` errors for all but cell method constructs

[davidhassell]

Hi @sadielbartholomew - great, sounds like we have a plan, then. I'm happy to make the suggested change to the docstring for now, and we'll refactor the Constructs object for a future (not 1.8.9.0) release.

[davidhassell]

Hi @sadielbartholomew, the short answer is that in the current CF data model, cell method constructs must be orderable but there is no defined ordering for any other type of construct (such as dimension coordinate constructs).

Would this change to the docstring work?

        For cell method constructs, the predetermined order is that in
        which they where added. There is no predetermined ordering for all other
        construct types, and a exception is raised if any non-cell method constructs
        are present.

[davidhassell]

Just had a look around the code a bit more .... (e.g.

cfdm/cfdm/core/constructs.py

Lines 256 to 257 in e908dc8

	for x in self._ordered_constructs:
	self._constructs[x] = OrderedDict()

)

I'm reminded that some of this logic stems from the fact that pre Python3.7 we needed to use OrderedDict for cell methods, but that is not necessary for 3.7 onwards. I think we are close to dropping 3.6 support (meaning we should do this!), as it is no longer supported by numpy 1.20. In this case, we can simplify (and speed up!) the code by getting rid of the "ordered" functionality completely (including the Constructs.ordered method) - we just say that constructs, of any flavour, are returned in the order in which they were set. This order happens to be arbitrary for all constructs except cell methods, for which this order determines the sequence in which the cell methods were applied to the data.

How does that sound?

[sadielbartholomew]

Thanks for the clarification @davidhassell. That makes sense, though as it is currently I don't think that context is clear (I certainly got confused as you can see!).

Would this change to the docstring work?

That makes it much clearer, thanks. Would you like to make that change or shall I (I guess we can't drop 3.6 support immediately for the next release)?

In this case, we can simplify (and speed up!) the code by getting rid of the "ordered" functionality completely (including the Constructs.ordered method) - we just say that constructs, of any flavour, are returned in the order in which they were set.

Brilliant, let's do that. Simple and means we don't need to treat cell methods as the one orderable special case.

[sadielbartholomew]

Great, thanks @davidhassell.