On Wed, Aug 16, 2006 at 03:25:39PM -0700, John Machin wrote: > > Jack Diederich wrote: > > On Wed, Aug 16, 2006 at 02:39:24PM -0700, John Machin wrote: > > > > > > Jack Diederich wrote: > > > > > > > Changing the PySequence_SetItem to PyList_SetItem and dropping the > > > > DECREF works for me too (PyList functions steal a reference). I also > > > > tried setting the list to length 1, still no dice. The PySequence > > > > version segs under 2.4 and 2.5. It segs even when the Int is changed > > > > to a String. > > > > > > > > Yikes, I'll poke around some more. > > > > > > Yikes indeed. > > > > > > Not the OP's problem, but a bug in the manual: example in the chapter > > > that the OP was reading acts as though the 2nd arg to PyObject_SetItem > > > is a C int (as it is for the List and Sequence varieties) -- it is in > > > fact a (PyObject *), which explains the SystemError that I got. > > > > The good news is that this is a documentation problem. > > Cop-out alert! I disagree. Elsewhere Python goes to great lengths to > check for nasties instead of just segfaulting. > > > When working at the C level you use the concrete API when you can > > (PyList_*) and at the abstract level (PySequence_*) only when someone > > passes you something and you don't know what it is, you only know it > > supports the Sequence API. > > > > The exmample should use the PyList API to construct the list. The > > Sequence API requires valid objects to work. Here the object is only half > > constructed and list_ass_item tries to DECREF the zeroth member which > > is NULL because the list isn't constructed yet. PyList_SetItem does > > an XDECREF (decrement only if the pointer isn't null) because it expects > > to be used that way. > > PyList_SetItem is not sentient. It expects nothing. Now tell us what > the developer was thinking -- certainly not consistency with the > documantation. If the Sequence API requires valid objects to work, > then in this case it should raise an error. > > In fact that manual section calls using the PySequence_SetItem the > recommended approach!!! > > Are you suggesting a rework of the manual instead of inserting a X in > the offending py_DECREF? > > Sheesh all round ...
It takes a big man to admit when he's wrong so I'll blame low blood sugar. Since this had been the same going all the way back to 2.2 I assumed it was common. It isn't, simlar functions in other objects guard against the possibility. I'll check in the change assuming no one else has already (and assuming the trunk isn't currently frozen, I'll have to check). -Jack -- http://mail.python.org/mailman/listinfo/python-list
