[Python-Dev] Null checking

[Guido van Rossum]

> 1. Public API functions should always do explicit NULL checks on
>    pointer arguments, and it's the user's fault if they pass a NULL.
>    A NULL argument should never crash Python regardless.

This is violated in 99% of the code (you've got to start writing more
code, Tim :-).  My position is different: extensions shouldn't pass
NULL pointers to Python APIs and if they do it's their fault.

> > I note that the null_error() check in abstract.c is non-destructive: it
> > preserves any existing error, whereas other checks (e.g. in typeobject.c)
> > do not.
> 
> Different authors.  Guido is omnipotent but not omnipresent <wink>.
> It would be good (IMO) to expose something like null_error in the
> public API, to encourage NULL-checking.  I don't know that there's
> real value in trying to preserve a pre-existing exception, though
> (if the code is hosed, it's hosed).

That was a specific semantic trick that Jim tried to use (see my
previous mail).  I guess the idea whas that you could write things
like

PyObject_DelItemString(PyObject_GetAttr(PyEval_GetGlobals(), "foo"), "bar").

But this never caught on -- I'm sure in a large part because most
things require you to do a DECREF if the result is *not* NULL.

It *is* handy in Py_BuildValue(), and that has now grown a 'N' format
that eats a reference to an object.  Both 'O' and 'N' formats return
NULL while preserving an existing error if the see a NULL.

--Guido van Rossum (home page: http://www.python.org/~guido/)