[Python-Dev] Null checking

Tim Peters tim.one@comcast.net
Mon, 10 Jun 2002 09:55:12 -0400

[Tim, howling in the wildnerness]
>> 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.

Then let's compromise:

0. All functions in the API, whether public or private, that don't
   intend to do something sensible with a NULL pointer argument,
   should assert non-NULL-ness.

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

You may have noticed that I've been spending much of my recent life checking
in changes to clean up stray references when Zope's BTree code finds a
reason to exit prematurely.  It's due to a different set of mechanisms, but
the pattern is clear <wink>.

No more on null_error() from me.