[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. [Guido] > 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.
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