[Numpy-discussion] Fix to #789 maybe not right.

Travis E. Oliphant oliphant@enthought....
Wed May 21 23:55:45 CDT 2008

Charles R Harris wrote:
> On Wed, May 21, 2008 at 9:32 PM, Travis E. Oliphant 
> <oliphant@enthought.com <mailto:oliphant@enthought.com>> wrote:
>     Charles R Harris wrote:
>     > Really, all the increments and decrements should be inside
>     > PyArray_FromArray, but calls to this function are scattered all
>     over.
>     I don't understand what you mean by this statement.    All functions
>     that return an object and take a PyArray_Descr object steal a
>     reference
>     to the descriptor (even if it fails).   That's the rule.
> Why should it not increment the reference itself? Note that calls to 
> this function are normally preceded by incrementing the reference, 
> probably because one wants to keep it around.
I wouldn't say normally.   I would say sometimes.   

Normally you create a reference to the data-type and want 
PyArray_FromAny and friends to steal it (i.e. PyArray_DescrFromType). 

I wouldn't call stealing a reference count a side effect, but even if 
you want to call it that, it can't really change without a *huge* 
re-working effort for almost zero gain.   You would also have to re-work 
all the macros that take type numbers and construct data-type objects 
for passing to these functions.   I don't see the benefit at all.
> I think it would be clearer to have the rule: you increment it, you 
> decrement it.
Maybe, but Python's own C-API doesn't always follow that rule, there are 
functions that steal references.   Remember, PyArray_Descr was 
retrofitted as a Python Object.  It didn't use to be one.   This steal 
rule was the cleanest I could come up with --- i.e. it wasn't an idle 

It actually makes some sense because the returned array is going to 
"own" the reference count to the data-type object (just like setting to 
a list).


More information about the Numpy-discussion mailing list