Martin Panter added the comment:

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.

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue1753718>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to