I understood “bytes-like” to mean what is now defined in the glossary: what is accepted by the C-level y* format for the PyArg parsing functions. I tend to agree with <https://bugs.python.org/issue23756#msg248265> that it may not have been the best term to choose when you really mean “C-contiguous buffer”.

I am understanding that you take “bytes-like” to be a more specific thing. Perhaps we could instead have two distinct terms, say “C-contiguous buffer”, which is what FileIO.write() and PyArg supports, and “byte sequence”, perhaps implementing an API common to bytes() and memoryview(), which is easier to work with using native Python.

In general, I think ctypes and array.array produce my stricter kind of C-contiguous buffers. But since Issue 15944 native Python code can access these buffers by casting to a second memoryview:

>>> c = ctypes.c_char(b"A")
>>> with memoryview(c) as array_view, array_view.cast("B") as byte_view:
...     print(repr(byte_view[0]))
... 
65

Nick’s commit d90f25e1a705 mentions multi-dimensional input for the “modern” interface. That is not the problem. In <https://bugs.python.org/issue17839#msg198843> he decided to be less permissive for the “legacy” interface, which seems unnecessary to me.

Anyway, this is all rather off-topic. Apart from the bytes-like errors, the rest of the current patch is good. Even if you committed with those four errors, I can live with that. I think there are similar problems elsewhere in the documentation, HTTPConnection.request() over TLS for instance.