tuple creation in C extensions

[Thomas Wouters]

On Wed, Jun 14, 2000 at 11:16:50AM +0000, Louis M. Pecora wrote:

> > Wow, thanks for looking that code over, Bernhard.  What a horrible bunch
> > of holes.

> And who could have seen all that so clearly without an expert on hand. 
> Even then I couldn't understand all the reasoning.  In Python we are all
> happy, but the ugly side is when we return to C.  It's obvious to me:

> CAN'T SOMEONE UPDATE THE EXTENSIONS PDF MANUAL, ADDING A BETTER TUTORIAL
> ON REFERENCE COUNTS AND (!!) LISTING Py_XXXX FUNCTIONS AND THEIR REFERENCE
> EFFECTS ??

Sure, anyone can. The address to submit your new sections is
python-docs at python.org, I believe. Note that you shouldn't send in PDF
documents. The actual documentation is written in TeX, which is used to
generate PostScript, PDF, HTML, info and what not. I'm sure someone will
volunteer to rewrite your plaintext-version to TeX if you write a good
manual on reference counts ;-)

> Sorry to yell, but it's obvious that many people like me are stumbling
> with this one.  I'd hate to have all that time I save using Python eaten
> up by debugging C extensions.

The API interface documentation is pretty clear in which functions give or
take a reference. *most* functions do not touch references, they take the
object you give to them, do their thing, and return a result. Those that
return objects are documented as returning either a new reference or a
borrowed reference (in which case, if you keep the object around, you have
to INCREF yourself) and those that steal a reference (take an Object
argument without returning it, and without INCREFing it) are documented to
do so as well.

The only trouble I had with refcounting (while writing the
augmented_assignment patch) was not bothering to see wether PyDict_SetItem()
stole a reference or not. It doesn't, but I did INCREF, so I was leaking ;-P

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!