[Numpy-discussion] Bug in resize method?
tim.hochberg at ieee.org
Wed Aug 29 14:31:12 EDT 2007
On 8/29/07, Anne Archibald <peridot.faceted at gmail.com> wrote:
> On 29/08/2007, Timothy Hochberg <tim.hochberg at ieee.org> wrote:
> > The main inconsistency I see above is that resize appears to only
> > ownership of the data if in fact the number of items changes. I don't
> > that's actually a bug, but I don't like it much; I would prefer that
> > be strict and always require ownership. However, I'm fairly certain that
> > there are people that prefer "friendliness" over consistency, so I
> > be surprised to get some pushback on changing that.
> It seems to me like inplace resize is a problem, no matter how you
> implement it --- is there any way to verify that no view exists of a
> given array? (refcounts won't do it since there are other, non-view
> ways to increase the refcount of an array.)
I think that may be overstating the problem a bit; refcounts should work in
the sense that they would prevent segfaults. They'll just be too
conservative in many cases, preventing resizes in cases where they would
> If there's a view of an
> array, you resize() it in place, and realloc() moves the data, the
> views now point to bogus memory: you can cause the python interpreter
> to segfault by addressing their contents. I really can't see any way
> around this; why not remove inplace resize() (or make it raise
> exceptions if the size has to change) and allow only the function
Probably because in a few cases, it's vastly more efficient to realloc the
data than to copy it.
FWIW, I don't use either the resize function or the resize method, but if I
was going to get rid of one, personally I'd axe the function. Resizing is a
confusing operation and the function doesn't have the possibility of better
efficiency to justify it's existence.
. tim.hochberg at ieee.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion