fix: listarray - slicing expects scalars

[ianna]

fixes issue #2068

[codecov]

Codecov Report

Merging #2069 (6dbf0a7) into main (7d38ba1) will not change coverage.
The diff coverage is 100.00%.

Additional details and impacted files

Impacted Files	Coverage Δ
src/awkward/contents/listarray.py	90.08% <100.00%> (ø)

[ianna]

@agoose77 - I haven't checked if you might have fixed it already?

[agoose77]

Nope, I haven't touched this yet!

[agoose77]

Ah I see, so this bug occurs because CuPy returns 0-D arrays instead of scalars. This is annoying! I think your fix looks like the best option available; we want to convert these to primitive types as soon as possible.

One request: could we change x.item() for int(x)? It would be one-less thing that typetracer needs to implement (even though this is a known_data branch).

[ianna]

Ah I see, so this bug occurs because CuPy returns 0-D arrays instead of scalars. This is annoying! I think your fix looks like the best option available; we want to convert these to primitive types as soon as possible.

One request: could we change x.item() for int(x)? It would be one-less thing that typetracer needs to implement (even though this is a known_data branch).

done

[jpivarski]

Just changing int to item.

[jpivarski]

One request: could we change x.item() for int(x)?

Oops—I just noticed that. I thought your opinion was the other way around. Is it because you'll be swapping method calls for function calls (although int isn't an nplike function)?

As I said, I only have a slight preference for item; it's because int looks like a mistake and I'd have to remind myself of this issue with CuPy to know why it's there. I was assuming that this method call (item) would be replaced by an nplike function (either item or a name that array libraries are unlikely to take in the future).

[agoose77]

I made the case to @ianna to change this, but it was only a mild preference. Given that we both have mild preferences, let's just accept this as-is!

[agoose77]

(@ianna feel free to merge!)