[SciPy-dev] Some suggestions for scipy_core

Travis E. Oliphant oliphant.travis at ieee.org
Sun Jan 1 21:34:01 CST 2006

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.


More information about the Scipy-dev mailing list