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 <[email protected]>
<http://bugs.python.org/issue1753718>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
