Author loewis
Recipients amaury.forgeotdarc, barry, donmez, giampaolo.rodola, gpolo, loewis, pitrou, teoliphant
Date 2008-07-26.13:07:32
SpamBayes Score 3.84258e-05
Marked as misclassified No
Message-id <488B2192.3040605@v.loewis.de>
In-reply-to <1216977371.14.0.264260457721.issue3139@psf.upfronthosting.co.za>
Content
> (1) are you sure it is safe not to INCREF the obj pointer in the
> Py_buffer?

Yes, that's the semantics of the current buffer interface, and I cannot
see a flaw in it. When you call getbuffer, you certainly hold a
reference, and it is your obligation to hold onto this reference
somehow. So it is definitely safe (if properly documented).

> It would seem more logical for PyBuffer_FillInfo to
> INCREF the obj, and for PyBuffer_Release to DECREF it and set it to NULL.

Perhaps. I cannot quite see what undesirable consequences that might
have - feel free to develop and test an alternative patch that takes
that approach.

> (2) is it necessary to call directly bf_getbuffer & the like or is there
> a higher-level API to do it?

There is PyObject_GetBuffer and PyObject_ReleaseBuffer, but it is not
higher-level. I need to check the function pointers, anyway (to
determine whether the object supports getbuffer and requires
releasebuffer or not), so calling them directly is the right level
of abstraction (IMO).

> (3) didn't you forget to convert "PyArg_ParseTuple(args, "s#iO:sendto",
> [...])" in sock_sendto?

True.

> (4) is it really necessary to do a special case with PyString_Check()
> rather than rely on the string type's getbuffer method?

That's what the code always did (for s#). It would be possible to
eliminate that case, yes.
History
Date User Action Args
2008-07-26 13:07:35loewissetspambayes_score: 3.84258e-05 -> 3.84258e-05
recipients: + loewis, barry, teoliphant, amaury.forgeotdarc, pitrou, giampaolo.rodola, donmez, gpolo
2008-07-26 13:07:33loewislinkissue3139 messages
2008-07-26 13:07:32loewiscreate