Terry J. Reedy added the comment: 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 https://docs.python.org/3/library/stdtypes.html#printf-style-string-formatting https://docs.python.org/3/library/stdtypes.html#printf-style-bytes-formatting 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. ---------- assignee: -> docs@python components: +Documentation nosy: +docs@python, eric.smith, terry.reedy _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28415> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
