# [Numpy-discussion] Ransom Proposals

Christopher Barker Chris.Barker at noaa.gov
Tue Mar 28 10:45:05 CST 2006

```I want to start by saying a am +1 on everything Tim is advocating, just
so you all know it's not just him. I'm not writing any code, however.

Travis Oliphant wrote:

> It would seem that most of Tim's complaints are directly against
> polymorphism.

I don't think so. I think Tim (and I) just want it to be really clear
what the polymorphic functions are and what aren't. Also, for
polymorphism to work, there always has to be some definition of what
"similar" objects are: in static languages, this means they are derived
from the same class. In duck-typed languages, it means they share the
same behavior, so all we're doing here is deciding exactly how much
behavior they need to share.

>  But, then Python has
> this same problem, because
>
> l += a
>
> doesn't do 'in-place' for the list, but does do inplace if 'l' were an
> array.

Yes, it does do it for the list, but differently. However, maybe a tuple
is a better example:

>>> a = (1,2,3)
>>> id(a)
331328
>>> a += (3,4,5)
>>> a
(1, 2, 3, 3, 4, 5)
>>> id(a)
236712

Whereas with numpy:

>>> import numpy as N
>>> a = N.array((1,2,3))
>>> id(a)
6436864
>>> a += (3,4,5)
>>> a
array([4, 6, 8])
>>> id(a)
6436864

So there are two differences: addition is defined differently, and one
is in-place, and one isn't. Personally, I've always thought that the "in
place" operators should never work with immutable types: in=place should
mean in-place,, not "in-place if possible, but not if not possible. and
yes, this is completely analogous to the issue at hand.

>>> l = [1,2,3]
>>> l
[1, 2, 3]
>>> a
array([4, 6, 8])
>>> l += a
>>> l
array([ 5,  8, 11])

>>> b
[4, 6, 8]
>>> l = [1,2,3]
>>> l += b
>>> l
[1, 2, 3, 4, 6, 8]

>>> l = [1,2,3]
>>> t = (3,4,5)
>>> l+=t
>>> l
[1, 2, 3, 3, 4, 5]

How this is anything but a bug is beyond me! Lists do define the
in-place operator, and really do it in-place. That being the case, I
would certainly never expect += to change the type of a list! It doesn't
with a tuple. Is this a numpy issue or a Python one?

> I don't view it as a problem of
> function behavior as much as problem with documentation and "mismatch
> between what a particular user expects and what is actually done."

Quite true. However, what I advocate is that to keep that mismatch as
rare as possible, the ONLY functions that should have the "sometimes a
view and sometimes a copy" behavior should be functions that explicitly
exist to provide that behavior, such as asarray(). All it does is save
typing and increase the potential for confusion and errors to built it
in to functions that have other uses.

Travis Oliphant wrote:

> on making methods that return views raise an error when impossible and
> not changing and/or deprecating functions (i.e. the functions are simple
> wrappers around the methods).

+1

> on making methods that return views raise an error when impossible and
> changing the function to make a copy

+1 : Only if the functions are moved to a separate "backwards
compatible" name space.

-Chris

--
Christopher Barker, Ph.D.
Oceanographer

NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov

```