[Numpy-discussion] Response to PEP suggestions

[konrad.hinsen at laposte.net]

On 20.02.2005, at 00:55, Robert Kern wrote:

>> They could all derive from a common (yet-to-be-written) base class  
>> that  has no data layout at all.
>
> We then end up with the same chicken-egg problem as accepting rank-0  
> integer arrays as indices. It won't work until it's in the core. If  
> I'm

True. We could have a patch to Python for testing purposes before such  
a decision, but this is not an ideal situation.

> understanding your proposition correctly, it also creates another  
> problem: rank-n arrays would then pass this check, although they  
> shouldn't.

No. My proposal is to have new Python scalar types, which are distinct  
from the array type(s). The new scalar types would use rank-0 arrays as  
their internal representation, but that would be an implementation  
detail not visible to users.

> I expect so, too. However, when considering additions to the standard  
> library, python-dev has to assume otherwise. If it's going to be so  
> limited in application, then something so large shouldn't be in the  
> standard library.

I am not so sure about this. There is some very domain-specific stuff  
in the standard library.

> I think it would be great to have a more thorough number hierarchy in  
> the standard library. So would some others. See PEPs 228 and 242.  
> However, I think that the issue is orthogonal getting an multiarray  
> object into the standard library. I'm not convinced that it actually  
> solves the problems with

The common point is just the community that is interested in this.  
However, there might be a wider interest in a re-working of the number  
hierarchy. There have been additions to the number hierarchy that don't  
come from the numerics community, such as the decimal number type. I  
think that a more open number hierarchy, into which modules could add  
their own types, could make it into the core if it doesn't cause any  
compatibility problems. In fact, this may be easier to argue for than  
having array methods on all scalar types.

Konrad.
--
------------------------------------------------------------------------ 
-------
Konrad Hinsen
Laboratoire Leon Brillouin, CEA Saclay,
91191 Gif-sur-Yvette Cedex, France
Tel.: +33-1 69 08 79 25
Fax: +33-1 69 08 82 61
E-Mail: khinsen at cea.fr
------------------------------------------------------------------------ 
-------