Re: [Numpy-discussion] Bug in numarray.typecode()?

[Philip A. <pa...@eo...>]

Todd Miller writes:
 > > 
 > > Should this print 'U'?
 > 
 > I think it could,  but I wouldn't go so far as to say it should. 
 > typecode() is there for backward compatibility with Numeric.  Since 'U'
 > doesn't work for Numeric,  I see no point in adding it to numarray. I'm
 > not sure it would hurt anything other than create the illusion that
 > something which works on numarray will also work on Numeric.
 > 
 > If anyone has a good reason to add it,  please speak up.
 > 

I don't necessarily need typecode, but I couldn't find the
inverse of

a = array([10], type = 'UInt8') (p. 19) 

in the manual.

That is, I need a method that returns the string representation of a
numarray type in a single call (as opposed to the two-step
repr(array.type()).  This is for code that uses the Boost C++ bindings
to numarray.  These bindings work via callbacks to python (which
eliminates the need to link to the numarray or numeric api). Currently
I use typecode() to get an index into a map of types when I need to
check that the type of a passed argument is correct:

void check_type(boost::python::numeric::array arr, 
		string expected_type){
  string actual_type = arr.typecode();
  if (actual_type != expected_type) {
    std::ostringstream stream;
    stream << "expected Numeric type " << kindstrings[expected_type]
	   << ", found Numeric type " << kindstrings[actual_type] << std::ends;
    PyErr_SetString(PyExc_TypeError, stream.str().c_str());
    throw_error_already_set();
  }
  return;
}

Unless I'm missing something, without typecode I need a second
interpreter call to repr, or I need to import numarray and load all
the types into storage for a type object comparison.  It's not a
showstopper, but since I check every argument in every call, I'd like
to avoid this unless absolutely necessary.

Regards, Phil