RetroSearch Browse

Mon Apr 9 18:59:10 CEST 2007 · https://mail.python.org/pipermail/python-dev/2007-April/072621.html

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 
>> > unexpected.
>> Yes, I agree. We had something like that at one point.
>
>
> Maybe this could be handled in an intermediate layer
> between the user and implementor of the interface,
> i.e. the user calls
>
>   PyBuffer_GetBuffer(obj, &info, flags);
>
> the object's tp_getbufferinfo just gets called as
>
>   getbufferinfo(self, &info)
>
> and PyBuffer_GetBuffer then checks that the result
> conforms to the requested feature set. This would
> relieve users of the interface from having to check
> that themselves, while not requiring implementors
> to be burdened with it either.

I like this strategy.    Then, any intermediate buffering (that prompted 
the killed release-buffer object in the protocol) could be handled in 
this layer as well.

I also like the idea of passing something to the getbuffer call so that 
exporters can do less work if some things are not being requested, but 
that the exporter should be free to ignore the flag and always produce 
everything.

-Travis

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2007-April/072621.html below:

[Python-Dev] Extended buffer PEP