fix: allow int as placeholder array index type

[pfackeldey]

This PR allows integer indexing on Placeholder arrays, because we know that an int will return a new_length of 1. This is a typical operation that happens when calling repr of an awkward-array.

This is useful, because instead the repr building for (usually broken) awkward-arrays that contain Placeholder arrays will currently generate a rather cryptic error:

...
TypeError: PlaceholderArray supports only trivial slices, not int

where it's rather unclear what the underlying reason was.

With this PR, the repr can be built, and it shows the missing entries as ??:

<Array [{run: [??], ...}, ..., {run: ..., ...}] type='40 * {run: uint32, lu...'>

which at least gives a better hint on which columns are still placeholders given that they have ?? as entry.

This is a problem that typically occurs if the ak.Form of an array has entries without matching buffers.

cc @ikrommyd

[pfackeldey]

I think this would help for the errors seen in scikit-hep/uproot5#1349 and scikit-hep/coffea#1231

[pfackeldey]

This is also maybe worth a discussion on what the policy should be here.
Allowing the arrays to be constructed instead of throwing an error when building the repr has the advantage of inspecting the array to understand what went wrong. But it also may hide the fact that the arrays is broken in the first place...

[jpivarski]

Would this work if it returned

type(self)(self._nplike, (), self._dtype)

instead? That is, a zero-dimensional array, which is more like a scalar than a one-dimensional, length-one array.

Also, the shape of a PlaceholderArray can be more than 1-dimensional, right? In that case, the return value wouldn't be scalar.

[agoose77]

@pfackeldey my feeling here is that we shouldn't allow indexing on placeholders; they should only arise in contexts where indexing hasn't taken place.

The motivating issue for this PR is that an operation that does not occur at typetrace time is being performed after typetracing, which therefore performs an operation that wasn't anticipated, and fails.

My feeling is that we should watch the array repr to know about placeholders, instead!

[jpivarski]

I agree, @agoose77! It would be preferable to just have a better repr.

[pfackeldey]

I agree! I was already a bit uncomfortable with this PR, my proposal would be to close this one and I'll look into having a better repr.

[ikrommyd]

FYI: This did solve the problems in scikit-hep/coffea#1231. Just mentioning it here for documentation purposes.

[pfackeldey]

@ikrommyd the fix for scikit-hep/coffea#1231 is something else I assume. I'll try to understand what goes on there in detail. This PR would allow you to run the reproducer in this issue, but the output array can not be trusted to be a valid array - it was not fixing the root cause of it.
PR #3342 won't fix your reproducer either, but the error message is likely better, because awkward-array likely can build a representation of the array now (this is my current understanding/assumption).