--- Thomas Heller <thomas.heller@ion-tof.com> wrote:
> What if we would 'fix' the buffer interface?
>
This gets us part of the way there, but still has shortcomings. For one I,
and people more significant than me, would still need a type that
implemented the bytes object behavior. Everything but efficient pickling
_could_ be done with third party extensions, but ignoring pickling (which I
don't want to do), then we'd still have several significant third parties
reinventing the same wheel. To me at least, this feels like a battery that
should be included.
> Extend the PyBufferProcs structure by new fields:
>
> typedef size_t (*getlargereadbufferproc)(PyObject *, void **);
> typedef size_t (*getlargewritebufferproc)(PyObject *, void **);
>
How would you designate failure/exceptions? size_t is unsigned everywhere
I can find it, so it can't return a negative number on failure. I guess
the void** could be filled in with NULL.
>
> typedef struct {
> getreadbufferproc bf_getreadbuffer;
> getwritebufferproc bf_getwritebuffer;
> getsegcountproc bf_getsegcount;
> getcharbufferproc bf_getcharbuffer;
> /* new fields */
> getlargereadbufferproc bf_getlargereadbufferproc;
> getlargewritebufferproc bf_getlargewritebufferproc;
> } PyBufferProcs;
>
>
> The new fields are present if the Py_TPFLAGS_HAVE_GETLARGEBUFFER flag
> is set in the object's type. Py_TPFLAGS_HAVE_GETLARGEBUFFER implies
> the Py_TPFLAGS_HAVE_GETCHARBUFFER flag.
>
> These functions have the same semantics Scott describes: they must
> only be implemented by types only return addresses which are valid as
> long as the Python 'source' object is alive.
>
> Python strings, unicode strings, mmap objects, and maybe other types
> would expose the large buffer interface, but the array type would
> *not*. We could also change the name from 'large buffer interface'
> to something more sensible, currently I don't have a better name.
>
I've been trying to keep the proposal as unintrusive as possible while
still implementing the functionality needed. Adding more flags/members to
PyObjects and modifying string, unicode, mmap, ... feels like a more
intrusive change to me. I'm open to the idea, but I'm not ready to retract
the current proposal. Then there is still the problem of needing something
like a bytes object as mentioned above.
Cheers,
-Scott
__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4