Coding standards tweaks to daskified cube code #2416
Conversation
(cherry picked from commit 7f74405)
|
See the comments on #2415 for a discussion of why I've made these changes. |
See related query, here : https://github.com/SciTools/iris/pull/2415/files#r104770825 |
| cube_data = self._dask_array | ||
| else: | ||
| raise ValueError('This cube has no data, slicing is not supported') | ||
| cube_data = self._numpy_array |
There was a problem hiding this comment.
@dkillick At this point, we're confident that either self._dask_array or self._numpy_array is populated.
Prior to this change, there seems to be a hint of that might not be the case, hence the ValueError exception being raised. I'd certainly hope that there is a data payload of some kind to process - we need to make sure that internally that is always the case.
There was a problem hiding this comment.
I think if we end up at this point having a cube with no data we're deeper in the sticky than a ValueError will help with! The rest of the code in the class makes it clear that we can never construct a cube with no data, so if an end user has done something that means their cube no longer has any data then IMO they can dig their own way out of the sticky stuff...
There was a problem hiding this comment.
I'm really hoping that there never, ever is any sticky stuff 😉
It's just a note to ourselves really, that we need to ensure the integrity of the cube as best we can
There were a few inconsistencies in the
cube+daskcode, and instead of noting them down for further discussion, I thought I'd make a vessel for discussion (that is, this PR).A retargetting of #2415 to the base
dask_timed.