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