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
PyUnicode_FromFormat integer format handling different from printf about zeropad #72601
Comments
Although declared *exactly equivalent* to printf in the doc, PyUnicode_FromFormat could generate different result from printf with the same format. For example: from ctypes import pythonapi, py_object, c_int
f = getattr(pythonapi, 'PyUnicode_FromFormat')
f.restype = py_object
f(b'%010.5d', c_int(100))
'0000000100'
while printf outputs: printf("%010.5d\n", 100);
00100 I use both gcc and clang to compile and get the same result. gcc gives me a warning: warning: '0' flag ignored with precision and ‘%d’ gnu_printf format I am not sure this should be fixed. It seems the change could break backwards compatibility. |
To be more precise, C90, C99, C11 all say that ~"For d, i, o, u, x and X conversions, if a precision is specified, the 0 flag will be ignored." |
I presume that PyUnicode_FromFormat is responsible for the first of the following:
>>> '%010.5d' % 100
'0000000100'
>>> b'%010.5d' % 100
b'0000000100' I am strongly of the opinion that the behavior should be left alone and the C-API doc changed by either 1) replacing 'exactly' with 'nearly' or 2) adding the following: "except that a 0 conversion flag is not ignored when a precision is given for d, i, o, u, x and X conversion types" (and other exceptions as discovered). I took the terms 'conversion flag' and 'conversion type' from I consider the Python behavior to be superior. The '0' conversion flag, the '.' precision indicator, and the int conversion types are literal characters. If one does not want the '0' conversion, one should omit it and not write it to be ignored.
>>> '%10.5d' % 100
' 00100'
And I consider the abolition of int 'precision', inr {} formatting even better.
>>> '{:010.5d}'.format(100)
Traceback (most recent call last):
File "<pyshell#2>", line 1, in <module>
'{:010.5d}'.format(100)
ValueError: Precision not allowed in integer format specifier It has always been a source of confusion, and there is hardly any real-world use case for a partial 0 fill. |
Add a note block under Py*_FromFormat in unicode.rst and bytes.rst. Could Xiang or Terry help to review? Thanks. |
*Way* too wordy. In msg278666, I suggested minimal and terse alternatives. |
(Response to what I believe is latest patch.) In msg278666, my two suggestions were 'either...or', not both. The list came from Antti's msg278528, but the correct list for Python appears to be different, and different for bytes and unicode. When I made the suggestion, I did not realize that 'exactly' was repeated for each conversion type in a table. As a note, I think the following might work. "For <list of> conversion types, the 0-conversion flag has effect even when a precision is given." I also think that 'exactly could be dropped when it is not exactly true. |
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: