[Numpy-discussion] Fix to #789 maybe not right.
Travis E. Oliphant
oliphant at enthought.com
Thu May 22 00:55:45 EDT 2008
Charles R Harris wrote:
>
>
> On Wed, May 21, 2008 at 9:32 PM, Travis E. Oliphant
> <oliphant at enthought.com <mailto:oliphant at 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
decision.
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).
-Travis
More information about the NumPy-Discussion
mailing list