[Python-Dev] Null checking

[Michael Hudson]

"David Abrahams" <david.abrahams@rcn.com> writes:

> A couple of quick questions for the authors of the Python source: I notice
> that most, if not all, of the Python 'C' API includes null checks for the
> PyObject* arguments, meaning that you can't crash Python by passing the
> result of a previous operation, even if it returns an error.
> 
> First question: can that be counted on? Hmm, I guess I've answered my own
> question -- PyNumber_InPlaceAdd has no checks.

You got it.

> 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.
> 
> Second question: I guess I really want to know what the intention behind
> these checks is.

I'm not sure there is one.  It may just be a bad example of defensive
programming (cf. OOSC).

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

Well, if you're missing it, so am I.

I'd also like to know why all the (for instance) methods in
tupleobject.c start with "if (!PyTuple_Check(self)".  You'd have to
try REALLY hard to get those tests to fail...

Cheers,
M.

-- 
  Q: What are 1000 lawyers at the bottom of the ocean?
  A: A good start.
  (A lawyer told me this joke.)
                                  -- Michael Ströder, comp.lang.python