PySequence_SetItem

[John Machin]

Jack Diederich wrote:
> On Wed, Aug 16, 2006 at 03:25:39PM -0700, John Machin wrote:

> > > >
> > > > 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.

Please don't forget this which is definitely a bug in the docs.

> > >
> > > 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'm a bit curious here: tuples naturally don't fill in the sq_ass_item
slot and I couldn't think of another object that would be initialised
with NULL(s) in the expectation of being filled in later or maybe not
... enlightenment, please.

>
> 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).

For avoidance of doubt: the change is to use Py_XDECREF, yes/no?

Cheers,
John