[Numpy-discussion] Response to PEP suggestions

[Travis Oliphant]

> 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.

Guido might in Python 3000....

>
> 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.

I guess I don't consider arrays as generalized sequence objects.  Except 
for the Python Object array which might be.     Still, my views on this 
are really not central as I want to help get something together that a 
large majority of us can be satisfied with.  I'm really not interested 
in intentionally making something that is difficult to use and I am 
willing to bend on many things (especially if work-arounds are possible). 

It seems to me that the rank-0 array scalar problem is fundamental to 
the situation of trying to craft a Numerical-environment on top of a 
general-purpose one.    I don't see a "right solution" that would please 
all parties short of altering all Python scalars --- and that would 
likely upset an entirely different crowd.  I suppose that is why we have 
the compromise we do now. 

> 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.

The only utility might be speed because it is not too hard to see that 
rank-0 arrays that behave as part of a generic system of 
multidimensional arrays might carry quite a bit of baggage that is not 
needed if all you are every want is a scalar.    This distinction may 
not be possible to get rid of. 

To put it more clearly:  Is it possible to define a scalar that 
interacts seamlessly with a system of multidimensional arrays without 
slowing slowing it down for usage in other contexts?  

I don't know the answer, but it sure seems to be no.  I've looked at 
Piddle (PERL's equivalent to Numeric)  and they seem to do exactly the 
same thing (have a rank-0 array that is very different from the Perl 
scalar). 


Added to our problem is that we do not have much control over the 
definition of fundamental scalars in Python.   Guido has suggested that 
he may be willing to allow integers to get methods (how many methods I'm 
not sure --- I didn't push him.  He mentioned the possibility of adding 
a rank-inquiry method for example).   It would pleasantly surprise me if 
he were willing to give scalars all of the methods and attributes of 
arrays.

>
> 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.

A healthy use of int()  in indexing operations could fix this, but yes, 
I see compatibility as an issue.  I don't want to create 
incompatibilities if we can avoid it.    On the other hand, I don't want 
to continue with a serious design flaw just for the sake of 
incompatibility either (I'm still trying to figure out if it is a flaw 
or not, it sure seems like a hack).

Thanks for your continued help and advice.

-Travis