[Numpy-discussion] Response to PEP suggestions

[Colin J. Williams]

konrad.hinsen at laposte.net wrote:

> On 18.02.2005, at 23:45, Travis Oliphant wrote:
>
>> While open to the idea for Python 3000, Guido does not seem 
>> favorable  to the idea for Python 2.X The problem, Guido mentions was 
>> that  float-like objects can convert to ints by truncation and he 
>> doesn't  want to allow floats to be used as indexes.   He feels it 
>> would break  too much code.
>
>
> I can agree with that. Basically the problem is the type hierarchy 
> that  is too simple (but many if not most programming language suffer 
> from  that problem). Type conversions are all handled in the same way, 
> which  doesn't give enough flexibility. But we won't change that of 
> course.
>
>> Of course underneath, a is not an array of integers (it is an array 
>> of  homogeneous c-ints converted from the Python integer and so why 
>> should  a[0] be a Python integer).
>
>
> That would basically mean to change the status of arrays from  
> generalized sequence objects to something different. Why not, but 
> then  this should be made clear to the programmer, in particular by 
> having a  different printed representation for rank-0 arrays and 
> scalars. It also  means adding some conversion functions, e.g. for 
> extracting a Python  Object from a rank-0 Python Object array.
>
> Still, I am worried about two aspects:
>
> 1) The amount of confusion this generates among users. The 
> distinction  between scalars and rank-0 arrays has no utility for the 
> programmer, it  exists only for implementation and political reasons. 
> I am not looking  forward to explaining this in my Python courses for 
> beginners.

(+1)
If we consider an array as a sequence of objects  of a fixed type, 
numeric or other, it makes sense that when a single object is returned 
then an object of that type be returned, coverted if necessary for Int8 
etc.  Returning a zero rank array is an historical pain.

It might make sense if all traditional Python objects were of zero rank  
I can see no merit in that.

>
> 2) Compatibility with existing code. I am not sure I will convert my  
> code to such conventions any time soon, because it requires 
> inspecting  every single indexing operation in its particular context 
> to see if the  index could be a rank-0 integer array. There is no way 
> to spot those  cases by textual analysis. So this change could reduce 
> acceptance to  the point where there is no interest in pursuing the 
> project any more.
>
I thought that the intent of Numeric 3 was to produce the best - a new 
start, without being overly concerned about compatibility.

I was glad to see the proposal to abandon "ravel" ( a hangover from 
APL?).  Words should have a clear generally accepted meaning.  For 
"ravel" dictionary.com offers:

       1. To separate the fibers or threads of (cloth, for example);
          unravel.
       2. To clarify by separating the aspects of.
       3. To tangle or complicate.

Colin W.