cc @mattip for review.

Looks pretty good, actually getting it right with None being passed could be slightly annoying (i.e. require parsing – could be fast pathed, although it may be that it does not matter: parsing no arguments is pretty fast).

Yes, this was, indeed, annoying. The error checking and ndigits for round vs decimals for np.round made it impossible to pass the same arguments forward, so I had to handle that corner case, and that of course, introduced a lot of error handling.

Travis failure is unrelated.

jobs.include.arch: unknown value aarch64
jobs.include.arch: unknown value aarch64 

That seems like a travis glitch, since the aarch64 builds have been around since Jan 2020.

Thanks @hameerabbasi, lets put this in, it seems good to me with the last modifications, thanks for staying with this, its always a bit more complicated than anticipated :).

Would this change have impacted how np.round() treats scalars? I am trying to chase down a bug where np.round([x]) is producing a different value sometimes from np.round(x).

No, we didn't change np.round, only ndarray.__round__.

@WeatherGod do you have a reproducer or similar? One thing is that round seems to call multiple, and true_divide internally with double precision numbers. So for the scalar case, we are likely using double precision calculations, but for [x] we would be using single precision in those calculations.

Still waiting for the actual data from my co-worker, but we have figured out that the problem is not in np.round(), but apparently different rules for upcasting calculations involving numpy scalars versus numpy arrays. I'll dig a bit more and see if a new bug report is warranted.