fix!: always broadcast with_field assignments against existing array

[agoose77]

This PR fixes #1936 by removing the branch in which no broadcasting takes place.

It also narrows the acceptable type of where from an iterable (of strings) to a sequence,

Note

This is a small change, but I want to justify it in the wider context of Awkward.

We currently do iterable→sequence conversion internally, and I don't think there's any benefit to accepting an iterable. My view is that unless you can naturally express an algorithm without consuming the iterable, then it's better just to accept sequences.

If we wanted to retain the iterable type without converting the iterable to a sequence, then we'd need to do something like

if ak._util.is_sized_iterable(where):
    tail = iter(where)
    head = next(tail)
    if not isinstance(head, str):
        raise ...    

There's no performance benefit for the user, or readability benefit for us.

---

📚 The documentation for this PR will be available at https://awkward-array.readthedocs.io/en/agoose77-fix-item-assignment/ once Read the Docs has finished building 🔨

[codecov]

Codecov Report

Merging #1962 (50bea08) into main (4e4bb54) will increase coverage by 0.00%.
The diff coverage is 100.00%.

Additional details and impacted files

Impacted Files	Coverage Δ
src/awkward/operations/ak_with_field.py	100.00% <100.00%> (+2.12%)	⬆️

[jpivarski]

There's a Python culture of being willing to accept Iterables instead of concrete lists, but we've run into trouble a few times with this policy because we often want to call len on the collection we're given.

So it needs to be a Sized Iterable: that would be exactly the level of abstraction we want, since this is something that's guaranteed to have __len__ and __iter__. Usually with our input collections, we don't use anything more than that.

Sequence is more: in addition to the above, it also has __getitem__, and if you're emulating a class (as opposed to accepting arguments, as in this case), it will also make a bunch of methods you don't want: __contains__, __reversed__, index, count. But here, we're just accepting arguments and having too many methods doesn't matter.

Sized Iterable is not a combination that people care about much in the Python world, so we can jump over that Goldilocks solution to requiring Sequences.

Actually, I'm probably even overthinking it. This is fine. :)

[agoose77]

Plus, we can always relax this if it becomes important.