[Python-Dev] buffer interface for C extensions
Hi all,
I've written a small C extension to submit commands to SCSI devices via
Linux's sg_io driver (for a camera hacking project). The extension is
just a wrapper around a couple ioctl()'s with Pythonic exception handling
thrown in. One of my extension methods is called like this from python:
sg.write(fd, command[, data, timeout)
Both command and data are binary strings. I would like to be able to use
either a regular Python string or an array('B', ...) for these read-only
arguments. So I tried to use the "t#" argument specifier to indicate that
these arguments could be either strings or objects that implement the read-
only buffer interface:
if (!PyArg_ParseTuple(args, "it#|t#i:write", &sg_fd, &cmd,
&cmdLen, &buf, &bufLen, &timeout))
return NULL;
Now, this works fine with strings, but when I call it with an array I get
a TypeError:
TypeError: write() argument 2 must be string or read-only character
buffer, not array.array
So, I then tried changing "t#" to "w#" to indicate that the arguments must
implement the /read-write/ buffer interface. Now the array objects work,
but when I try a string argument, I naturally get this error:
TypeError: Cannot use string as modifiable buffer
So here's what I don't understand. Why doesn't the "t#" argument
specifier support read-write buffers as well as read-only buffers? Aren't
read-write buffers a *superset* of read-only buffers?? Is there something
I'm doing wrong or a quick fix to get this to work appropriately?
Thanks for any help!
Dan
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] buffer interface for C extensions
On Sun, 18 May 2008 22:59:05 +, Dan Lenski wrote:
> So here's what I don't understand. Why doesn't the "t#" argument
> specifier support read-write buffers as well as read-only buffers?
> Aren't read-write buffers a *superset* of read-only buffers?? Is there
> something I'm doing wrong or a quick fix to get this to work
> appropriately?
So... I've answered my own question on this. I had a look in getargs.c,
and apparently the "t#" argument specifier only accepts *character-based*
readable buffers.
Is there any chance anyone of adding an argument specifier for readable
buffers in general? Say, "r#"?
Can anyone explain to me the rationale for having some data type support
the readable buffer interface, but /NOT/ the character-based buffer
interface? I can't find any information that explains the fundamental
distinction between the two... and I don't see why array('B') shouldn't
support both.
Dan
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] buffer interface for C extensions
On Thu, 22 May 2008 23:10:09 +0200, M.-A. Lemburg wrote: > On 2008-05-19 00:59, Dan Lenski wrote: > You should probably ask such questions on the capi-sig list. > > To answer your question: > > t# requires support for the read-only 8-bit character buffer interface > s# can use the read buffer interface > w# requires support for the write buffer interface I somehow overlooked the fact that the "s#" argument specifier supports exactly the functionality that I need. D'oh! > Those are two different buffer interface slots, so whether a particular > object works with t# or w# depends on whether it implements the slots in > question. > > You should probably try s#, as this will also work with objects that > implement the getreadbuffer slot. Worked like a charm! > The details can be found in Python/getargs.c I'm still unclear on the difference between the character/read buffer interfaces, but I'll read the code and try and figure that out. Thanks for your help, Marc-Andre!!! Dan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
