Dave Opstad wrote: > In article <[EMAIL PROTECTED]>, > "John Machin" <[EMAIL PROTECTED]> wrote: > > > What is the purpose of this first loop? > > Error handling. If I can't successfully create all the PyInts then I can > dispose the ones I've made and not bother making the tuple at all. > > > > In what variable-length storage are you storing these (Python) integers > > during this first loop? Something you created with (a) PyMem_Malloc (b) > > malloc (c) alloca (d) your_own_malloc? > > (b) malloc. The sequence here is: 1) malloc; 2) check for malloc > success; 3) loop to create PyInts (if failure, Py_DECREF those made so > far and free the malloc'ed buffer); 4) create new tuple (error checks
> again); and 5) PyTuple_SET_ITEM (no error checks needed) Don't. If you _must_ allocate your own storage, use PyMem_Malloc. > > > 1. Determine the length of the required tuple; this may need a loop, > > but only to _count_ the number of C longs that you have. > > 2. Use PyTuple_New. > > 3. Loop to fill the tuple, using PyInt_FromLong and PyTuple_SetItem. > > This would certainly be simpler, although I'm not sure I'm as clear as > to what happens if, say, in the middle of this loop a PyInt_FromLong > fails. I know that PyTuple_SetItem steals the reference; does that mean > I could just Py_DECREF the tuple and all the pieces will be > automagically freed? If so, I'll take your recommendation and rework the > logic this way. This is what I believe happens. However even if you did need to do more cleaning up, you shouldn't penalise the normal case i.e. when PyInt_FromLong works. The only failure cause AFAIK is running out of memory. This should be rare unless it's triggered by your calling malloc :-) -- http://mail.python.org/mailman/listinfo/python-list