Tue, 11 Aug 2015 14:53:47 -0400 reachableroots: return NULL if we're throwing an exception
Augie Fackler <augie@google.com> [Tue, 11 Aug 2015 14:53:47 -0400] rev 26010
reachableroots: return NULL if we're throwing an exception Based on my reading of [0] and surrounding sections, if we want an exception to be properly raised when something goes wrong in the C code, we need to make sure we return NULL here. Do so. https://docs.python.org/2/extending/extending.html#back-to-the-example
Tue, 11 Aug 2015 15:34:10 -0400 reachableroots: fix transposition of set and list types in PyArg_ParseTuple
Augie Fackler <augie@google.com> [Tue, 11 Aug 2015 15:34:10 -0400] rev 26009
reachableroots: fix transposition of set and list types in PyArg_ParseTuple This is being masked by the function not properly returning NULL when it raises an exception, so the client code was just falling back to the native codepath when it got None back. A future change removes all reason for this C function to return None, which exposed this problem during development.
Tue, 11 Aug 2015 14:50:39 -0400 reachableroots: consistently use short-form of PyErr_NoMemory()
Augie Fackler <augie@google.com> [Tue, 11 Aug 2015 14:50:39 -0400] rev 26008
reachableroots: consistently use short-form of PyErr_NoMemory()
Tue, 11 Aug 2015 14:49:40 -0400 reachableroots: if allocating a new set fails, use PyErr_NoMemory()
Augie Fackler <augie@google.com> [Tue, 11 Aug 2015 14:49:40 -0400] rev 26007
reachableroots: if allocating a new set fails, use PyErr_NoMemory() My inspection of the implementation of PySet_New() indicates that it does *not* reliably set an exception in the cases where it returns NULL (as far as I can tell it'll never do that!), so let's set that up ourselves.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -4 +4 +10 +30 +100 +300 +1000 +3000 +10000 tip