[Numpy-discussion] Fix to #789 maybe not right.
Travis E. Oliphant
Wed May 21 23:55:45 CDT 2008
Charles R Harris wrote:
> On Wed, May 21, 2008 at 9:32 PM, Travis E. Oliphant
> <firstname.lastname@example.org <mailto:email@example.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
> I don't understand what you mean by this statement. All functions
> that return an object and take a PyArray_Descr object steal a
> 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
More information about the Numpy-discussion