There’s also a number of asymmetries here:
- In the future, we’ll iterate over the object or throw an error. You can always treat objects as scalars, but you cannot always treat them as iterables. By defaulting to errors for non-iterables, it’s a great big signal for library creators that they can opt-in to acting like a scalar if it is appropriate.
- End-users can opt-in to scalar-like behaviors by wrapping in another broadcastable container (like
Refor 1-tuples or 0-dimensional arrays). Were we to default to treating everything like a scalar, that means that they would have to collect an iterable into a different broadcastable structure in order to iterate over it. - In 0.6 and prior, we had it the other way around —defaulting to scalar-like behavior it meant that it was up to each library and type to decide how they’d behave. Even with base itself, this led to lots of surprises — some folks wanted to iterate over sets but treat dicts as scalars. Or broadcasting the array-ish Linear Algebra
Iobject was quite a surprise.
There’s going to be some pain in converting to this new system, but I think the resulting consistency will make it much easier to understand what a given broadcasting expression will do.