Reverting #694

[jpivarski]

PR #694 silently introduced a new slicing rule: if slicing with variable-length dimensions but one dimension has regular length 1, it would be expanded to fit the array you're slicing, to allow this:

array = ak.Array(
    [
        [[0, 1, 2, 3, 4], [5, 6, 7, 8, 9], [10, 11, 12, 13, 14]],
        [[15, 16, 17, 18, 19], [20, 21, 22, 23, 24], [25, 26, 27, 28, 29]],
    ]
)
slicer = ak.Array([[3, 4], [0, 1, 2, 3]])
assert array[slicer[:, np.newaxis]].tolist() == [
    [[3, 4], [8, 9], [13, 14]],
    [[15, 16, 17, 18], [20, 21, 22, 23], [25, 26, 27, 28]],
]

The rule was introduced because it simplifies expressions in this tutorial that was never presented: https://github.com/jpivarski-talks/2021-02-09-propose-scipy2021-tutorial/blob/main/prep/million-song.ipynb (it was a proposal that wasn't accepted, and hence wasn't developed beyond its currently rough state).

The rule was justified because length-1 dimensions are expanded to fit the dimensions of other arrays in broadcasting, and NumPy advanced indexing broadcasts all arrays in a tuple before applying them as a slice, and I wanted a similar effect. However, there are several differences from the NumPy case: Awkward advanced indexing involves a single nested array, which has to match dimensions with the array you're slicing, whereas NumPy advanced indexing involves a tuple of arrays that get broadcasted together; in no case is the array used as a slice broadcasted with the array being sliced. The analogy is a little weak.

Moreover, the new rule has led to some erroneous cases, described in #1022, especially #1022 (comment). (The length-1 dimensions were supposed to be made with np.newaxis, but there are other ways to "accidentally" make length-1 dimensions.) Although the rule has been in the codebase for 6 months, it has never been advertised and probably hasn't been triggered until now because it relies on a mixture of regular and variable-length axes. (@agoose77 uses regular and mixed dimensions a lot.)

Therefore, I will be removing this feature, restoring the "you need all dimensions in the slicer to be regular or variable-length" behavior that predated this rule. Slices like the above are still possible, but are more laborious to set up:

assert array[[[[3, 4], [3, 4], [3, 4]], [[0, 1, 2, 3], [0, 1, 2, 3], [0, 1, 2, 3]]]].tolist() == [
    [[3, 4], [8, 9], [13, 14]],
    [[15, 16, 17, 18], [20, 21, 22, 23], [25, 26, 27, 28]],
]

(The [3, 4] is replicated as many times as the length of the first list in array and the [0, 1, 2, 3] is replicated as many times as the second list in array. If this needs to be a common idiom, we can find other ways to construct it; it's slicer[[[0, 0, 0], [1, 1, 1]]].)

This is not something that would be easy to turn into a deprecation cycle—note to self: I should not introduce slicing rules lightly!—but it turns something that is currently poorly defined into an error message. If you see this error message:

ValueError: slice items can have all fixed-size dimensions (to follow NumPy's slice rules) or they can have all var-sized dimensions (for jagged indexing), but not both in the same slice item

In something that worked in awkward>=1.1.0rc2,<=1.4.0 and doesn't work in awkward>1.4.0, then it is likely this. If this is still a need (originally issue #492), we'll find a different solution, some function that modifies the slicer to fit the array to be sliced, rather than implicitly taking regular length-1 dimensions to do that automatically.

[jpivarski]

PR #1028 removes the slice feature, as described above. It's an almost exact inverse of #694.