Greg Ewing wrote:
> Travis Oliphant wrote:
>
>> Carl Banks wrote:
>> > I'd like to see it accept a flags argument over what kind of buffer
>> > it's allowed to return. I'd rather not burden the user to check
>> all > the entries in bufferinfo to make sure it doesn't get something
>> > unexpect
Here is my "final" draft of the extended buffer interface PEP.
For those who have been following the discussion, I eliminated the
releaser object and the lock-buffer function. I decided that there is
enough to explain with the new striding and sub-offsets without the
added confusion of rel
Travis Oliphant wrote:
> Carl Banks wrote:
> > I'd like to see it accept a flags argument over what kind of buffer
> > it's allowed to return. I'd rather not burden the user to check all
> > the entries in bufferinfo to make sure it doesn't get something
> > unexpected.
> Yes, I agree. We had s
Carl Banks wrote:
> Only one concern:
>
> > typedef int (*getbufferproc)(PyObject *obj, struct bufferinfo
> *view)
>
>
> I'd like to see it accept a flags argument over what kind of buffer
> it's allowed to return. I'd rather not burden the user to check all
> the entries in bufferinfo to m
Only one concern:
> typedef int (*getbufferproc)(PyObject *obj, struct bufferinfo *view)
I'd like to see it accept a flags argument over what kind of buffer it's
allowed to return. I'd rather not burden the user to check all the
entries in bufferinfo to make sure it doesn't get something
