Is there a reason not just to modify format_longdouble and friends, adding extra arguments for the new features? That way, the code path is mostly shared between scalar repr and array repr.

I left format_longdouble alone since I didn't want to modify the scalar printing, which appears to be intentionally different from the array element printing (it includes a trailing 0). I also don't see much point in adding a lot of generalized code for the scalars if we will never use it.

Also, format_longfoat was already its own special function in the multiaraymodule, so I am just leaving it that way.

Also, just a comment on the state of float printing in numpy and python: It's messy.

We use C's printf to print numpy scalars, but we use python's printf-formatting to print array elements, and the two are not the same. CPython actually uses the dtoa algorithm for float printing, I think because they decided that the OS printf was unreliable and sometimes inaccurate. dtoa is advertised to be a highly accurate and also human-friendly way to print floats.

Using C's printf is not ideal since we have to to a lot of string manipulation to reformat the OS printf output to be what we want (see numpyos.c), to account for locale, exponent digits, and other things. CPython falls back to using the same methods if dtoa.c is not available for some reason.

Other languages like Julia, Go, Rust, javascript in some browsers, have decided that the OS printf was unreliable, and use specific float printing algorithms. They seem to use some combination of dtoa, an algorithm called grisu3 (dtoa is apparently based on grisu2), and one called dragon4.

Here are some links to discussion of these issues:

Blog Post about Dragon4 and Grisu3
Swift discussion of grisu3 vs dtoa, with more links
Python issue discussing dtoa improvements

Probably in an ideal world numpy would include a good float-printing algorithm, perhaps customized for our requirements (eg, for output alignment). But we have lived without one until now, so I don't think it's very high priority.

Hmm, some of the numpy problems in my last comment might be solved by using calls to PyOS_double_to_string instead of PyOS_snprintf in the numpy scalar float formatting code, since the former uses the dtoa algorithm. We would need to write wrapper code to account for whitespace padding, exponent padding, like CPython does somewhere in the formatting code too.

One last comment:

I don't think the dtoa library can accurately print IEEE-extended precision floats (ie 80-bit long double on x64). We may have to rely on the OS printf for that, doubly so because the format of long double is arch-dependent.

note: this PR is addressing issue #9699