[Python-Dev] Omit Py_buffer struct from Stable ABI for Python 3.2?

Antoine Pitrou solipsis at pitrou.net
Wed Jan 5 15:24:29 CET 2011


On Wed, 5 Jan 2011 14:03:41 +0000
Mark Dickinson <dickinsm at gmail.com> wrote:
> On Wed, Jan 5, 2011 at 1:13 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> > On Wed, 5 Jan 2011 12:55:55 +0000
> > Mark Dickinson <dickinsm at 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.


More information about the Python-Dev mailing list