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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4