On 8/29/07, Anne Archibald <[EMAIL PROTECTED]> wrote: > > On 29/08/2007, Timothy Hochberg <[EMAIL PROTECTED]> 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. -- . __ . |-\ . . [EMAIL PROTECTED]
_______________________________________________ Numpy-discussion mailing list [email protected] http://projects.scipy.org/mailman/listinfo/numpy-discussion
