On Wed, 5 Jan 2011 14:03:41 +0000 Mark Dickinson <dicki...@gmail.com> wrote: > On Wed, Jan 5, 2011 at 1:13 PM, Antoine Pitrou <solip...@pitrou.net> wrote: > > On Wed, 5 Jan 2011 12:55:55 +0000 > > Mark Dickinson <dicki...@gmail.com> wrote: > >> The need for obj is a little ugly: as far as I can tell, it's > >> meaningless for a 3rd-party object that wants to export buffers---it's > >> only really used by the memoryview object and by internal Python > >> types. > > > > I don't think it's ugly. It's the only way to know which object exported > > a Py_buffer. Otherwise you have to track the information separately, > > which is quite a bit uglier (especially when in conjunction with > > PyArg_ParseTuple and friends). > > Maybe I'm misunderstanding. What's the responsibility of a buffer > export w.r.t. the obj field---i.e., what should 3rd party code be > filling that obj field with in a call to getbuffer?
It would let PyBuffer_FillInfo() do the job. If it doesn't want to, it must put itself in that field, and increment its reference count. > It looks to me as though it's really the memoryview object that needs > this information; No, anyone wanting to release a buffer without keeping separate track of the original object needs it. As I said, this also applies to users of PyArg_ParseTuple and friends ("s*", "y*" etc. format codes). > Isn't that what the 'base' field in PyMemoryViewObject in PEP 3118 was > supposed to be for? Perhaps, but practice (implementing "s*" etc.) suggested it was useful in other cases. That field ('base') is removed in 3.2. Regards Antoine. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com