[SciPy-user] Changed attributes .dtypedescr, .dtypechar, .dtypestr and .dtype
oliphant.travis at ieee.org
Sat Jan 14 21:45:55 CST 2006
There was some cruft left over from the change to making data-type
descriptors real Python objects. This left lots of .dtype related
attributes on the array object --- too many as Francesc Altet graciously
In the latest SVN, I've cleaned things up (thanks to a nice patch from
Francesc to get it started). Basically, there is now only one
attribute on the array object dealing with the data-type (arr.dtype).
This attribute returns the data-type descriptor object for the array.
This object itself has the attributes .char, .str, and .type (among
I think this will lead to less confusion long term. The cruft was due
to the fact that my understanding of the data-type descriptor came in
December while seriously looking at records module.
This will have some backward-compatibility issues (we are still pre-1.0
and early enough that I hope this is not too difficult to deal with).
The compatibility to numpy-0.9.2 issues I can see are:
1) Replacing attributes that are now gone:
.dtypechar --> .dtype.char
.dtypestr --> .dtype.str
.dtypedescr --> .dtype
2) Changing old .dtype -> .dtype.type
This is only necessary if you were using a.dtype as a *typeobject*
issubclass(a.dtype, <some scalar type>)
If you were using .dtype as a parameter to dtype= then that usage
will still work
great (in fact a little faster) because now .dtype returns a
3) The dtypedescr constructor is now called dtype.
This change should have gone into the 0.9.2 release, but things got too
hectic with all the name changes. I will quickly release 0.9.4 with
these changes unless I hear strong disagreements within the next few days.
SciPy SVN has been updated and fixed with the changes.
Numeric compatibility now implies that .typecode() --> .dtype.char
although if .typecode() was used as an argument to a function, then
.dtype will very likely work.
More information about the SciPy-user