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 _______________________________________________ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
