[Numpy-discussion] Bug in resize method?

[Timothy Hochberg]

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
> require
> > ownership of the data if in fact the number of items changes. I don't
> think
> > that's actually a bug, but I don't like it much; I would prefer that
> resize
> > be strict and always require ownership. However, I'm fairly certain that
> > there are people that prefer "friendliness" over consistency, so I
> wouldn't
> > 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
otherwise work.


> 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
> resize()?


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...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20070829/c8533be4/attachment.html>