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