Is "t#" argument format meant to be char buffer, or just read-only?
I fixed the crasher for ``int(buffer(array.array('c')))`` by making buffer objects operate properly. Problem is that by doing so I broke the ctypes tests with a bunch of similar errors:: ====================================================================== ERROR: test_endian_double (ctypes.test.test_byteswap.Test) ---------------------------------------------------------------------- Traceback (most recent call last): File "/code/python/trunk/Lib/ctypes/test/test_byteswap.py", line 134, in test_endian_double self.failUnlessEqual(bin(struct.pack("d", math.pi)), bin(s)) File "/code/python/trunk/Lib/ctypes/test/test_byteswap.py", line 7, in bin return hexlify(buffer(s)).upper() TypeError: requested buffer type not available Turns out the test does the following:: binascii.hexlify(buffer(ctypes.c_double(math.pi))) This is a problem because binascii.hexlify() uses "t#" as its argument format string to PyArg_ParseTuple() and that fails now with a TypeError since ctypes.c_double (which subclasses ctypes._SimpleCData which defines the buffer interface) does not have a char buffer defined. Now this used to pass since buffer objects just used the read or write buffer in place of the char buffer, regardless if the wrapped object had a char buffer function defined. But in checking out what "t#" did, I found a slight ambiguity in the docs. The docs say "read-only character buffer" for the short description, but "read-only buffer" for the longer description. Which is it? Plus, Thomas, you might want to change _SimpleCData if you want it to truly suport char buffers. -Brett
Brett Cannon wrote:
I fixed the crasher for ``int(buffer(array.array('c')))`` by making buffer objects operate properly. Problem is that by doing so I broke the ctypes tests with a bunch of similar errors::
You have not yet committed this fix, right?
====================================================================== ERROR: test_endian_double (ctypes.test.test_byteswap.Test) ---------------------------------------------------------------------- Traceback (most recent call last): File "/code/python/trunk/Lib/ctypes/test/test_byteswap.py", line 134, in test_endian_double self.failUnlessEqual(bin(struct.pack("d", math.pi)), bin(s)) File "/code/python/trunk/Lib/ctypes/test/test_byteswap.py", line 7, in bin return hexlify(buffer(s)).upper() TypeError: requested buffer type not available
Turns out the test does the following::
binascii.hexlify(buffer(ctypes.c_double(math.pi)))
This is a problem because binascii.hexlify() uses "t#" as its argument format string to PyArg_ParseTuple() and that fails now with a TypeError since ctypes.c_double (which subclasses ctypes._SimpleCData which defines the buffer interface) does not have a char buffer defined.
Now this used to pass since buffer objects just used the read or write buffer in place of the char buffer, regardless if the wrapped object had a char buffer function defined.
But in checking out what "t#" did, I found a slight ambiguity in the docs. The docs say "read-only character buffer" for the short description, but "read-only buffer" for the longer description. Which is it?
I am using binascii.hexlify(buffer(obj)) as a simple way to look at the bytes of the memory block. I think that hexlify should be able to use any buffer object that has a readable memory block, not only those with charbuffers. The docs say that the binascii methods are used to "convert between binary and various ASCII-encoded binary representations".
Plus, Thomas, you might want to change _SimpleCData if you want it to truly suport char buffers.
I did not implement that because the memory block contains binary data, not text. Thomas
Thomas Heller wrote:
I think that hexlify should be able to use any buffer object that has a readable memory block, not only those with charbuffers.
The docs say that the binascii methods are used to "convert between binary and various ASCII-encoded binary representations".
So why the heck is hexlify looking for charbuffers and not byte buffers in the first place? -- Greg
On 6/8/06, Thomas Heller
Brett Cannon wrote:
I fixed the crasher for ``int(buffer(array.array('c')))`` by making buffer objects operate properly. Problem is that by doing so I broke the ctypes tests with a bunch of similar errors::
You have not yet committed this fix, right?
Nope; I was waiting to hear back on all of this; no committing of code that knowingly breaks tests and all.
======================================================================
ERROR: test_endian_double (ctypes.test.test_byteswap.Test) ---------------------------------------------------------------------- Traceback (most recent call last): File "/code/python/trunk/Lib/ctypes/test/test_byteswap.py", line 134, in test_endian_double self.failUnlessEqual(bin(struct.pack("d", math.pi)), bin(s)) File "/code/python/trunk/Lib/ctypes/test/test_byteswap.py", line 7, in bin return hexlify(buffer(s)).upper() TypeError: requested buffer type not available
Turns out the test does the following::
binascii.hexlify(buffer(ctypes.c_double(math.pi)))
This is a problem because binascii.hexlify() uses "t#" as its argument format string to PyArg_ParseTuple() and that fails now with a TypeError since ctypes.c_double (which subclasses ctypes._SimpleCData which defines the buffer interface) does not have a char buffer defined.
Now this used to pass since buffer objects just used the read or write buffer in place of the char buffer, regardless if the wrapped object had a char buffer function defined.
But in checking out what "t#" did, I found a slight ambiguity in the docs. The docs say "read-only character buffer" for the short description, but "read-only buffer" for the longer description. Which is it?
I am using binascii.hexlify(buffer(obj)) as a simple way to look at the bytes of the memory block.
I think that hexlify should be able to use any buffer object that has a readable memory block, not only those with charbuffers.
The docs say that the binascii methods are used to "convert between binary and various ASCII-encoded binary representations".
Perhaps s# should be used instead since the docs say a read buffer can be used for that.
Plus, Thomas, you might want to change _SimpleCData if you want it to
truly suport char buffers.
I did not implement that because the memory block contains binary data, not text.
OK. -Brett
participants (3)
-
Brett Cannon -
Greg Ewing -
Thomas Heller