This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients chuck, exarkun, georg.brandl, gregory.p.smith, ivank, loewis, pitrou
Date 2009-09-27.15:03:32
SpamBayes Score 1.299513e-07
Marked as misclassified No
Message-id <1254064025.5532.5.camel@localhost>
In-reply-to <1253958556.69.0.190058284745.issue6071@psf.upfronthosting.co.za>
Content
> The first thing the function does is checking if the object implements 
> the old buffer api, but also fails if pb->bf_releasebuffer != NULL. So I 
> guess it's also making sure the new buffer api is not implemented.
> 
> What's the thought behind this?

The idea is that if a type implements the bf_releasebuffer function, it
shouldn't be used in a situation where the caller won't try to release
the buffer.

It looks a bit unwarranted though, because a type implementing the old
buffer API should be able to function without the releasing anyway.
Otherwise it wouldn't implement that API at all.

Martin, ISTR you did that addition, would you be opposed to removing the
NULL check on bf_releasebuffer when trying to get a buffer through the
old buffer API?
History
Date User Action Args
2009-09-27 15:03:35pitrousetrecipients: + pitrou, loewis, georg.brandl, gregory.p.smith, exarkun, ivank, chuck
2009-09-27 15:03:33pitroulinkissue6071 messages
2009-09-27 15:03:33pitroucreate