None of the QC or Modin Frame docstrings say a word about passing slices as indexers (view, getitem_row_array, mask), nevertheless, front-end code sometimes passes slices to the backend. Moreover,
modin_frame.mask has a logic of processing slices, although its docstring only allows passing list-like indexers.
I’m currently working on #3513 pull request that optimizes
__getitem__ flow of iloc/loc accessors, where sometimes it’s desired to pass a
slice to the backend’s
view method, however, it isn’t clear, whether I should avoid this or it’s allowed.
In the current implementation seen in the
modin/master slices are passed to the backend only if its step is 1. In the turn of
modin_frame.mask, it only can handle slices with 1 step as well (it doesn’t verify this, it just works incorrectly if the step is not 1). This interface seems easy breakable since it’s not documented anyhow and any accidental leak of a non-1-step slice may result in an undefined
We should get rid of this API inconsistency somehow. From my side, there are three different proposals:
- Allow passing any slices to the
modin_frame.maskand explicitly write it in the method’s contracts. This will require adding the full support of slices to the
- Allow passing only 1-step slices explicitly at the docstrings and add an assert statement on this to the
- Throw out
pandas.RangeIndexinstead. This won’t require us to change the function’s contract (backends are not forced to implement maybe complex logic of slice indexing), however, it still allows us to use all the benefits of indexing with slices if the
maskimplementation of the specific backend support this (it can check if the indexer is a range like and treat it as a slice).