isn't it a bug in array.fill()?
hi all, isn't it a bug (latest numpy from svn, as well as my older version) from numpy import array print array((1,2,3)).fill(10) None Regards, D.
On Fri, Aug 29, 2008 at 10:19 AM, dmitrey <dmitrey.kroshko@scipy.org> wrote:
hi all, isn't it a bug (latest numpy from svn, as well as my older version)
from numpy import array print array((1,2,3)).fill(10) None
Yeah, I do stuff like that too. fill works in place so it returns None.
x = np.array([1,2]) x.fill(10) x array([10, 10]) x = x.fill(10) # <-- Danger! print x None
Keith Goodman wrote:
Yeah, I do stuff like that too. fill works in place so it returns None.
x = np.array([1,2]) x.fill(10) x
array([10, 10])
x = x.fill(10) # <-- Danger! print x
None
Since result "None" is never used it would be better to return reference to the modified array, it would decrease number of bugs. The last expression can raise very seldom in untested cases, I have revealed one of this recently in my code: if some_seldom_cond: r = empty(n, bool).fill(True) else: r = None So, as you see, r was always None D.
On Fri, Aug 29, 2008 at 10:42 AM, dmitrey <dmitrey.kroshko@scipy.org> wrote:
Keith Goodman wrote:
Yeah, I do stuff like that too. fill works in place so it returns None.
x = np.array([1,2]) x.fill(10) x
array([10, 10])
x = x.fill(10) # <-- Danger! print x
None
Since result "None" is never used it would be better to return reference to the modified array, ...
I like that idea. A lot of numpy functions return a reference to the modified array when the output array (out) is specified.
On Fri, Aug 29, 2008 at 10:51 AM, Keith Goodman <kwgoodman@gmail.com> wrote:
On Fri, Aug 29, 2008 at 10:42 AM, dmitrey <dmitrey.kroshko@scipy.org> wrote:
Keith Goodman wrote:
Yeah, I do stuff like that too. fill works in place so it returns None.
x = np.array([1,2]) x.fill(10) x
array([10, 10])
x = x.fill(10) # <-- Danger! print x
None
Since result "None" is never used it would be better to return reference to the modified array, ...
I like that idea. A lot of numpy functions return a reference to the modified array when the output array (out) is specified.
But python doesn't do that. For example, x.sort() returns None in python. Should it return None in numpy?
Keith Goodman wrote:
On Fri, Aug 29, 2008 at 10:51 AM, Keith Goodman <kwgoodman@gmail.com> wrote:
On Fri, Aug 29, 2008 at 10:42 AM, dmitrey <dmitrey.kroshko@scipy.org> wrote:
Keith Goodman wrote:
Yeah, I do stuff like that too. fill works in place so it returns None.
x = np.array([1,2]) x.fill(10) x
array([10, 10])
x = x.fill(10) # <-- Danger! print x
None
Since result "None" is never used it would be better to return reference to the modified array, ...
I like that idea. A lot of numpy functions return a reference to the modified array when the output array (out) is specified.
But python doesn't do that. For example, x.sort() returns None in python. Should it return None in numpy?
I think the value "None" that any method always returns is hardly used by anyone, so backward compatibility will not suffer much. Since in-place modification remains (along with new-style returning value that is reference to the array), there should be no backward incompatibilities at all. D.
On Fri, Aug 29, 2008 at 11:51 AM, Keith Goodman <kwgoodman@gmail.com> wrote:
On Fri, Aug 29, 2008 at 10:42 AM, dmitrey <dmitrey.kroshko@scipy.org> wrote:
Keith Goodman wrote:
Yeah, I do stuff like that too. fill works in place so it returns None.
x = np.array([1,2]) x.fill(10) x
array([10, 10])
x = x.fill(10) # <-- Danger! print x
None
Since result "None" is never used it would be better to return reference to the modified array, ...
I like that idea. A lot of numpy functions return a reference to the modified array when the output array (out) is specified.
Google up the various discussions of python sort to see why Guido doesn't like that sort of thing. We've had that discussion on this list also and pretty much decided to follow python in these matters. Not that I really agree with Guido here, but it's a small point and when in Rome... Chuck
2008/8/29 Charles R Harris <charlesr.harris@gmail.com>:
I like that idea. A lot of numpy functions return a reference to the modified array when the output array (out) is specified.
Google up the various discussions of python sort to see why Guido doesn't like that sort of thing. We've had that discussion on this list also and pretty much decided to follow python in these matters. Not that I really agree with Guido here, but it's a small point and when in Rome...
At first, I also thought it might be more intuitive to return the output array, but then I realised that it would make it more difficult to realise that the operation is being performed in-place. Maybe it is good to remind programmers of what happens under the hood, so that they are not surprised later when their data is "corrupted". Stéfan
Stéfan van der Walt wrote:
At first, I also thought it might be more intuitive to return the output array, but then I realised that it would make it more difficult to realise that the operation is being performed in-place. Maybe it is good to remind programmers of what happens under the hood, so that they are not surprised later when their data is "corrupted".
That is essentially the core reason for the behavior of list.sort(). Cheers, Alan
On Fri, Aug 29, 2008 at 3:03 PM, Alan G Isaac <aisaac@american.edu> wrote:
Stéfan van der Walt wrote:
At first, I also thought it might be more intuitive to return the output array, but then I realised that it would make it more difficult to realise that the operation is being performed in-place. Maybe it is good to remind programmers of what happens under the hood, so that they are not surprised later when their data is "corrupted".
That is essentially the core reason for the behavior of list.sort().
IIRC, it is also the case that Guido doesn't like the a.foo().bar().oops() style of programming, preferring one operation/line. Chuck
I suppose all the discussion on comp.lang.python about list methods (especially sort) is becoming relevant to this thread. Cheers, Alan Isaac
participants (5)
-
Alan G Isaac -
Charles R Harris -
dmitrey -
Keith Goodman -
Stéfan van der Walt