[SciPy-dev] Some suggestions for scipy_core

[Travis E. Oliphant]

Francesc Altet wrote:
> Hi,
> 
> I've started looking at giving suport of scipy_core objects into
> PyTables. I begun by homogenous array (not chararrays or recarrays
> yet), and discovered some issues that perhaps can be improved in
> scipy_core:
> 
> 1.- Is there any reason for this?
> 
> In [67]: type(scicore.array(3, dtype='D'))
> Out[67]: <type 'scipy.ndarray'>
> 
> In [68]: type(scicore.array(3).astype('D'))
> Out[68]: <type 'complex128_arrtype'>        !!!!!!!!
> 

The reason is that you are getting an "array scalar" because 
0-dimensional arrays are only returned from the array function, itself.
All other functions return array scalars.

Please note that complex128_arrtype is an actual python type object that 
can hold a single item of the array.

> 
> 2.- For the sake of compatibility with numarray, I'm wondering if you
> can include entries in the typeDict dictionary that follows numarray
> conventions.
> 
> In [98]: scicore.typeDict['UInt16']
> ---------------------------------------------------------------------------
> exceptions.KeyError                                  Traceback (most
> recent call last)
> 
> /home/faltet/python.nobackup/scipy_core/<console>
> 
> KeyError: 'UInt16'
> 
> However, this exists:
> 
> In [99]: scicore.typeDict['Uint16']
> Out[99]: <type 'uint16_arrtype'>

This is a mistake.  Uint16 should *be* UInt16.   That is one of the big 
purposes of typeDict (compatibility with numarray).

> 
> Also, for numarray compatibility, could 'complexXXX' --> 'ComplexXXX'
> be made? And add a 'Bool'? I know that a type 'Bool8' exists, but
> perhaps 'Bool' can be added as an alias of 'Bool8'.

Sounds fine on the Bool.   But, note that unlike in numarray, the 
lower-case types are actual Python type objects.  The capitalized names 
are just string typecodes.   Also, ComplexXXX uses the old (bit-width of 
the float) convention for backwards compatibility, whereas the new 
complexXXX names use item-bit-width convention.

> 
> 3.- Finally, I'd advocate to have a more handy string representation
> for .dtype. Right now, one have:
> 
> In [117]: a.dtype
> --------> a.dtype()
> Out[117]: 0
> 
> (why dtype supports the call protocol? Is it really necessary?)
> 

Because it's an actual type object.  I think we could disable the tp_new 
method of the type.  Curently, this allows you do say int32([1,2,3,4]) 
to construct an array.


> In [118]: str(a.dtype)
> Out[118]: "<type 'int32_arrtype'>"
> 
> In [121]: repr(a.dtype)
> Out[121]: "<type 'int32_arrtype'>"

This would require creating a new metaclass because a.dtype is a 
typeobject and so prints using the standard type object printing.  We 
would have to inherit from the typeobject to change that standard.

I think rather than shield people from the idea that dtype is an actual 
typeobject (which changing the printing would do) we should emphaize 
that fact.


Thanks for your suggestions.

-Travis