Message71878
| Author |
pitrou |
| Recipients |
amaury.forgeotdarc, barry, benjamin.peterson, donmez, gpolo, lemburg, loewis, pitrou, teoliphant |
| Date |
2008年08月24日.21:24:41 |
| SpamBayes Score |
7.5241496e-07 |
| Marked as misclassified |
No |
| Message-id |
<1219613080.5635.10.camel@fsol> |
| In-reply-to |
<1219612406.28.0.241779655738.issue3139@psf.upfronthosting.co.za> |
| Content |
Hi Travis,
Glad you're back!
> I'm not convinced that Py_buffer should have grown a link to an object.
> I think this is a shortcut solution due to misuse of the protocol that
> may have unfortunate consequences.
What consequences are you thinking about?
Specifically, why shouldn't Py_buffer have a link to the object? It's
the best way we've found to be able to release the buffer without having
to keep a link to the originator ourselves. The concern is to simplify
the API for most of its users. Especially, the new format codes ("s*" et
al.) can just fill the Py_buffer rather than return several things at
once.
(please note that link can be NULL if you don't want to have the
associated resource management)
> I'm not sure where PyBuffer_Release came from. I can't find it in the
> PEP and don't remember what it's purpose is.
It's a replacement for PyObject_ReleaseBuffer(). Since a Py_buffer now
has a link to its originator, there's no need to pass it separately to
the releasing function. |
|