Per the documentation,"The alternate form causes a leading octal specifier ('0o') to be inserted before the first digit", However the actual behavior didn't conform to the principle. Code: >>>b'%#07o' % 34 Output: b'0000o42'

The link is https://docs.python.org/3.5/library/stdtypes.html#printf-style-bytes-formatting

The documentation matches the behavior. In this context "the first digit" is the 4. The leading zeros are the pad fill. Now, whether this is *useful* behavior or not is a separate question :) And yes, the docs could be clarified on this point either way.

Make a slight change to my code, which becomes `b'%#07x' % 34`, the weird situation appears.

This is not documentation issue, but a bug in formatting octals in bytes. >>> '%#07x' % 123 '0x0007b' >>> b'%#07x' % 123 b'0x0007b' >>> '%#07o' % 123 '0o00173' >>> b'%#07o' % 123 b'000o173' ^

Proposed patch fixes this inconsistency.

OK, that makes sense. Patch looks good to me.

New changeset 96d728c14267 by Serhiy Storchaka in branch '3.5': Issue #29000: Fixed bytes formatting of octals with zero padding in alternate https://hg.python.org/cpython/rev/96d728c14267 New changeset 29c9c414c310 by Serhiy Storchaka in branch '3.6': Issue #29000: Fixed bytes formatting of octals with zero padding in alternate https://hg.python.org/cpython/rev/29c9c414c310 New changeset 4e55e011dd80 by Serhiy Storchaka in branch 'default': Issue #29000: Fixed bytes formatting of octals with zero padding in alternate https://hg.python.org/cpython/rev/4e55e011dd80

Thanks David.