[David Abrahams, on NULL-checking in the source] > ... > Second question: I guess I really want to know what the intention behind > these checks is. Is it something like "prevent extension writers from > crashing Python in some large percentage of cases", or is there a deeper > plan that I'm missing? Different authors have different paranoia levels. My level is here, for functions that don't intend to accept NULL arguments: 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. 2. Private API functions should always assert non-NULL-ness on pointer arguments, and it's a bug in Python if a caller passes a NULL. Any place where the Python code base deviates from those is simply a place I didn't write <wink>. > 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).
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