Probably out of scope, but I wonder what happens if you set a custom array_repr() that simply points to the one used by ndarray, but then write your own array_add. Would the repr padding calculations (which sometimes use the array add) then go through the custom array_add instead of the ndarray version?

We don't expose the non-overloaded version of array_repr() externally, so I don't think this is possible.

I like that this splits up the numpy array_repr api and the array_repr implementation. I mentioned in another thread that ducktype implementors may want to reuse the implementation (after some changes to array2string), but before now there was no way to call it separately from the api method.

I still have a feeling this isn't the last change we will make here. For instance, I'm not 100% convinced that array_repr, array_str and array2string should be part of the __array_function__ api. Should they be part of the _array_function__-api, or are they simply one-off helper functions for __repr__ code? Does the fact that they nearly already work as-is when called on ducktypes suggest the latter? When do we ever want a ducktype's __repr__ to be different from its array_repr? I also find the arrays2string vs array2string.__wrapper__ juggling here convoluted and a sign that something isn't quite correctly organized, though I understand the technical reason for it.

Despite all that, this PR seems like a step forward for now, to get things in a working state, so I would merge it.

(Needs rebase though).

Should they be part of the array_function_-api, or are they simply one-off helper functions for repr code? Does the fact that they nearly already work as-is when called on ducktypes suggest the latter? When do we ever want a ducktype's repr to be different from its array_repr?

"One-off helper functions" seems cleaner to me, but already expose them in NumPy's top level API which suggests they need __array_function__.

If I were starting from scratch I would probably only expose arary2string in NumPy's top level namespace, which would make this whole thing cleaner.

All right, LGTM, merging. Thanks Stephan.