Unsurprisingly (libmpdec is a C library) this also does not work in _decimal. I could add a special case in _decimal.c at the cost of two additional if statements for all regular use cases. Is padding with NUL a legitimate use case? IOW, is the slowdown justified?
> Is padding with NUL a legitimate use case? I don't see a good reason to disallow it, and it seems like a fairly plausible need. Numpy, for example, pads strings will NUL bytes when placing a short string in long fixed-width field.
Mark Dickinson <report@bugs.python.org> wrote: > Numpy, for example, pads strings will NUL bytes when placing a short > string in long fixed-width field. I was hoping to escape the work, but that's quite convincing. ;) Changing libmpdec doesn't look very appealing, so probably I'll use "{" as a placeholder for NUL and then rewrite the result.
I worked on a patch that allows NUL padding for longs, floats and complex numbers. It seems NUL was being used as a sentinel in the format string parsing when no padding character is given. It was then replaced with a space in each call to fill_padding if it was NUL.
