Docstring says:

The signed keyword-only argument determines whether two's complement is
used to represent the integer.  If signed is False and a negative integer
is given, an OverflowError is raised.

But actually, 

    (130).to_bytes(1, 'big', signed=True)

will also trigger OverflowError

What is wrong?

The docstring does not say, that positive values also may raise OverflowError if it can not fit into `(byte_count * 8) - 1` bits.

I mean when signed=True

docstring says:

The integer is represented using length bytes.  An OverflowError is
raised if the integer is not representable with the given number of
bytes.

(Python 3.5.2)

Well. Phrase `If signed is False and a negative integer is given, an OverflowError is raised.` describe onlyhalf of behaviour. It does not explain behaviour when `signed=True` and value is big enough to trigger exception, but not enough to trigger it when signed=False.

So, in order to make documentation consistent, either new text should be added, or last phraze removed. That's what I think.

@mmarkk

Do you read full docstring?  It's documented very clearly.

---
int.to_bytes(length, byteorder, *, signed=False) -> bytes

Return an array of bytes representing an integer.

The integer is represented using length bytes.  An OverflowError is
raised if the integer is not representable with the given number of
bytes.

The byteorder argument determines the byte order used to represent the
integer.  If byteorder is 'big', the most significant byte is at the
beginning of the byte array.  If byteorder is 'little', the most
significant byte is at the end of the byte array.  To request the native
byte order of the host system, use `sys.byteorder' as the byte order value.

The signed keyword-only argument determines whether two's complement is
used to represent the integer.  If signed is False and a negative integer
is given, an OverflowError is raised.
---

The docstring looks correct to me. The last phrase corresponds to the last paragraph that describes the signed keyword-only argument.

Is there anyone else for whom the docstring looks wrong?

Looks correct to me as well.  If you can think of a wording that would be clearer, Марк, that would be great, but it shouldn't make the docstring much wordier (we strive for conciseness in docstrings).  That last phrase can't be just removed without omitting an important piece of information (an *additional* time OverflowError can be raised).

Ok. This is minor fix, I will not fight for my point of view :)