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
NDCubeSequence.index_as_cube calls cube_utils.index_sequence_as_cube which creates an item_tuple containing the information needed to slice the NDCubeSequence. But depending on whether the information requested as part of this slicing spans multiple cubes or not, and the way in which the user input the slice, item_tuple can take multiple forms which makes the code difficult to understand and debug. Therefore, the code should be simplified/make more intuitive, without changing the user-facing functionality.
One possible solution is to have a new class, say SequenceSlice, whose __init__ takes an slicing item and returns an object with the slice for the first, last, and intermediate cubes which are requested as part of the slicing. This object would have this information is the same format regardless of how the user input the original slicing information and so would make the under-the-hood code easier to follow and maintain.
Other suggestions are welcome.
The text was updated successfully, but these errors were encountered:
NDCubeSequence.index_as_cube
callscube_utils.index_sequence_as_cube
which creates anitem_tuple
containing the information needed to slice the NDCubeSequence. But depending on whether the information requested as part of this slicing spans multiple cubes or not, and the way in which the user input the slice,item_tuple
can take multiple forms which makes the code difficult to understand and debug. Therefore, the code should be simplified/make more intuitive, without changing the user-facing functionality.One possible solution is to have a new class, say
SequenceSlice
, whose__init__
takes an slicing item and returns an object with the slice for the first, last, and intermediate cubes which are requested as part of the slicing. This object would have this information is the same format regardless of how the user input the original slicing information and so would make the under-the-hood code easier to follow and maintain.Other suggestions are welcome.
The text was updated successfully, but these errors were encountered: