Message114053
> Note that the buffer interface release API is meant to protect
> against such modifications, so I don't see why rejecting objects
> that do implement this API should be rejected.
As I explained, the release API is *not* used by PyObject_AsCharBuffer() in Python 2.7 and 3.2.
Pseudo-code example:
---
PyObject_AsCharBuffer(obj, &str, &size)
... modify or destroy obj ...
str is no more valid here
---
> Restricting the API to read-only buffers would seriously limit
> it's functionality. I'm -1 on doing that.
PyObject_AsCharBuffer() is dangerous because the caller has to ensure that the object is not modified or destroyed. Antoine proposes to deprecated PyObject_AsCharBuffer().
PyObject_GetBuffer() can replace PyObject_AsCharBuffer(): it's easy to get the pointer to the buffer content (view.buf) and the size (view.len) using PyObject_GetBuffer(), and it does protect the buffer against modification or destuction thanks to the release API (PyBuffer_Release). But PyObject_GetBuffer() is maybe a little bit to low level, eg. it doesn't check that the buffer is contiguous, and it requires a flag argument. A new function is maybe needed to replace PyObject_AsCharBuffer(). Eg. PyObject_GetCharBuffer() which will call PyObject_GetBuffer() (the caller will then have to call PyBuffer_Release() to release the buffer).
Example:
---
PyObject_GetCharBuffer(obj, &view, &str, &size)
... use str and size ...
PyBuffer_Release(view);
---
or just
---
PyObject_GetCharBuffer(obj, &view)
... use view.buf and view.len ...
PyBuffer_Release(view);
--- |
|
Date |
User |
Action |
Args |
2010-08-16 17:02:33 | vstinner | set | recipients:
+ vstinner, lemburg, loewis, pitrou |
2010-08-16 17:02:33 | vstinner | set | messageid: <1281978153.17.0.301612840444.issue9602@psf.upfronthosting.co.za> |
2010-08-16 17:02:31 | vstinner | link | issue9602 messages |
2010-08-16 17:02:30 | vstinner | create | |
|