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.