Get rid of CubeList

[pp-mo]

I've been wondering about the value of CubeList, since

1. the recent sad demise of Should cubelists contain objects that are not cubes? #1897
2. the advent of Geovista, which for me is really highlighting the transparency benefit of not wrapping existing objects in a non-transparent way, i.e. working with PyVista objects not some derived thing.
   I accept that the CubeList is only an "enhanced list", and this should be easy to use and undertand. But from experience with other users' code in support queries, it actually does confuse (see below)

So I think it's worth considering retire Cubelist + not have it at all
Here are some reasons ...

Noted that

• novice users have tended to think it is something that it is not -- e.g. that the cubes would share dimensions
• users generally (from looking at others' code) often assume that a CubeList is needed by operations that don't need it,
  e.g. (and perhaps especially) iris.save, as in save(CubeList(cubes), file)
• novice users also miss that CubeList can be used just like a plain list, when required.
  e.g. list_of_cubes = list(cubelist); cube_3 = list_of_cubes[3]

So, it does do a few things..

1. it provides a nice printout, with indices and one cube per line, which a list of cubes can't do.
2. it provides 'extract' and 'merge' and 'concatenate' operations.
3. err... that's about it ?

'Extract' and the like could very easily be provided by a library-level functions.
E.G.

from iris.constraints import merge_cubes, concatenate_cubes, extract_cubes
merge = merge_cubes([cube1, cube2])

IMHO this is actually simpler than the CubeList way, and clearer.

The printout problem is a little harder.
I don't see how you can get the same convenience of >>> cubes.
Any ideas ?

[jamesp]

xarray and pandas both go for the library-level function approach for this sort of operation, xarray.merge, pandas.concat, etc.

Ref. http://xarray.pydata.org/en/stable/user-guide/combining.html

So if we did something like that our API may be familiar to users of those libraries.

No idea on the cubelist printing though! As a somewhat advanced python programmer and occasional user of iris I find the cubelist printout to be confusing, at is at odds with how lists work in my mental model of python list printing. But that is not necessarily a general view.

[trexfeathers]

The printout problem is a little harder.
I don't see how you can get the same convenience of >>> cubes.
Any ideas ?

We could default Cube.__str__ to be the short summary. Then it wouldn't be much more work for a user to use pprint or "\n".join when printing the list. I don't consider this a breaking change, since the long summary is still available via Cube.summary(), and it would be an antipattern for anyone to be basing their workflows on string printouts. But such a change would require a lot of one line changes to our doctests!

[rcomer]

I've just been playing and found that, in ipython, the repr looks almost the same whether my cubes are in a CubeList, a list, a tuple or a set. Not so much in plain python though.

Perhaps a utility function could be provided to print what currently comes from CubeList.__str__. Added bonus if that function works with a file as well as a cube sequence.

If I'm working with a new data set, pretty much the first thing I'll do is load a whole file into ipython and print the cubelist to see what I'm working with. The fact that CubeList.__str__ provides the indices makes it really easy to get hold of a cube that looks useful and interrogate it further.

[rcomer]

I think I should repeat my assertion from #3429 (comment), #3429 (comment) that this kind of change is going to create a lot of work for users in updating existing code. We should consider whether it's worth it and/or whether there are ways to help make those changes less time consuming.

[trexfeathers]

Discussion from @SciTools/peloton:

We have two types of confusion:

• Being unable to put non-Cube objects in it - need to make clear that it's NOT a list
• Not knowing that list operations work on it - need to make clear that it IS a list

Would the breaking changes be worth it? There would be a lot of them - is the reduction in confusion worth it?