PySequence_SetItem

[Jack Diederich]

On Thu, Aug 17, 2006 at 02:35:11PM +0200, Fredrik Lundh wrote:
> John Machin wrote:
> 
> > 1. It's also documented as being the recommended way of filling up a
> > list after PyList_New.
> 
> since it doesn't work in any existing Python release, it's hardly "recommended".
> 
> the Python documentation has never been formally binding; if the documentation
> doesn't match the code, it's usually the documentation that's flawed.
> 
> > 2. So you'd rather not change the code, and just let it segfault if
> > someone calls it (or PyObject_SetItem) instead of PyList_SetItem?
> 
> as I said, you're using an API that's designed for use on *properly initialized*
> objects on an object that *hasn't been initialized*.  if you're going to patch all
> places where that can happen, you might as well rewrite the entire interpreter.
> 
> the documentation is broken, and *must* be fixed.  catching this specific case
> in the code is a lot less important; it's just one of many possible errors you can
> make when writing C-level code.  there's simply no way you can catch them
> all.
> 
This was my initial reaction and I'll reluctantly go back to it.  The docs
describe a bad practice - no one ever uses an abstract API to initialize the
concrete type they just created.  For bonus points the example would have always
segfaulted (at least back to 2.2, I didn't check 1.5).

While it feels uneven that other types can't get this kind of segfault the
fact that no one else has ever run accross it makes the point moot.

Unrelated, it looks like PySequence_* doesn't have much reason to live now
that iterators are everywhere.  In the core it mainly used to do the equiv of

def listize(ob):
  if (type(ob) in (list, tuple)):
    return ob
  else:
    return list(iter(ob))

-Jack