You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There's a tweak to CubeList.extract_strict which makes it return a single cube as it is, instead of return a "list of one cube".
We just documented this more fully
But, as mentioned there I don't personally like returning different types of object from different operations, which I think is a bit of an anti-pattern...
IIRC this is why we have provided other functions in multiple convenience versions,
like "load or load_cube" and "cube.coords or cube.coord" : these forms combine convenience + syntactic elegance with better clarity as to the exact function + interface.
Even more relevant, right here in CubeList, we have merge() / merge_cube() and concatenate / concatenate_cube.
In this case, there is a bit of an obstacle in the dual choice between "cube or cubes", and "strict or not". I guess we are not going to have all of "extract, extract_strict, extract_cube, extract_cube_strict" ...
To be definite, I propose we should drop extract_strictaltogether,
and replace it with extract_cube and extract_cubes.
I think that works, and would be much more in line with the other methods.
There's a tweak to CubeList.extract_strict which makes it return a single cube as it is, instead of return a "list of one cube".
We just documented this more fully
But, as mentioned there I don't personally like returning different types of object from different operations, which I think is a bit of an anti-pattern...
IIRC this is why we have provided other functions in multiple convenience versions,
like "load or load_cube" and "cube.coords or cube.coord" : these forms combine convenience + syntactic elegance with better clarity as to the exact function + interface.
Even more relevant, right here in CubeList, we have
merge()
/merge_cube()
andconcatenate
/concatenate_cube
.In this case, there is a bit of an obstacle in the dual choice between "cube or cubes", and "strict or not". I guess we are not going to have all of "extract, extract_strict, extract_cube, extract_cube_strict" ...
To be definite, I propose we should drop
extract_strict
altogether,and replace it with
extract_cube
andextract_cubes
.I think that works, and would be much more in line with the other methods.
So, for examples of usage change :
extract_strict(some_constraints)
-->extract_cubes(some_constraints)
.extract_strict(one_constraint)
-->extract_cube(one_constraint)
.The text was updated successfully, but these errors were encountered: