New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fill Character cannot be \0 #61905
Comments
The docs say: "The fill character can be any character other than ‘{‘ or ‘}’." http://docs.python.org/dev/library/string.html#format-specification-mini-language But: >>> "{0:\x01>8.2f}".format(12)
'\x01\x01\x0112.00' whereas: >>> "{0:\x00>8.2f}".format(12)
' 12.00' |
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 Is padding with NUL a legitimate use case? IOW, is the slowdown justified? |
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:
I was hoping to escape the work, but that's quite convincing. ;) Changing libmpdec doesn't look very appealing, so probably I'll use |
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. |
This looks like a duplicate of bpo-12546. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: