On Nov 30, 2009, at 7:26 PM, Lisandro Dalcin wrote:
> On Tue, Dec 1, 2009 at 12:09 AM, Robert Bradshaw
> <[email protected]> wrote:
>>
>>> BTW, I wouldn't mind extending the string input argument conversion
>>> support
>>> to everything that supports the buffer protocol.
>>
>> That might be interesting, though one difficulty is that buffers in
>> general don't have a intrinsic notion of length. (Technically, nor do
>> strings, null terminated strings encoded with null-free encodings are
>> common enough to make char* useable.)
>>
>
> I see, then in the near future I'll be able to create a numpy array
> with "unsigned char" dtype (let say, for storing a 8-bit image?). But
> at some point, I'll mistakenly pass these arrays to something
> accepting 'bytes'... No, -1, do not do that please. Explicit is better
> than exlicit. Error should never pass silently.
I agree, that would be bad.
What I was interpreting this as is one could write
def foo(int* data):
...
and data would be "extracted" via the buffer interface. That could get
messy with char*. I certainly don't support
def foo(bytes data):
...
accepting a buffer object, and automatically creating the bytes object
out of it. Doing some "magic" for C <-> Python conversion is a lot
more natural (even necessary) vs. doing magic to transform from one
kind of Python object to another.
- Robert
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
