> 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4