![](https://secure.gravatar.com/avatar/788e9f211717fff4949bef64aa7d3318.jpg?s=120&d=mm&r=g)
"NA_getType" needs to be documented. The following is useful: if (!PyArg_ParseTuple(args, "O", &type)) return NULL; temptype = NA_getType(type); if (temptype == NULL) return NULL; typeno = NA_typeObjectToTypeNo(temptype); Py_DECREF(temptype); if (typeno < 0) { PyErr_Format(PyExc_RuntimeError, "_numarray_init: can't get typeno for type"); return NULL; } Do other functions in "libnumarraymodule.c" need to be documented?
![](https://secure.gravatar.com/avatar/faf9400121dca9940496a7473b1d8179.jpg?s=120&d=mm&r=g)
There's a mix of "interface" and "implementation" in libnumarray since the API jump table mechanism is the only kind of inter-module linkage used. Since some of the functions in libnumarray are just there because they needed to be shared within the implementation, not exported as public interface, "everything" is never going to be documented. However, specific holes that people point out certainly can be. I'll document this one. Regards, Todd On Thu, 2003-10-23 at 20:48, Edward C. Jones wrote:
![](https://secure.gravatar.com/avatar/faf9400121dca9940496a7473b1d8179.jpg?s=120&d=mm&r=g)
There's a mix of "interface" and "implementation" in libnumarray since the API jump table mechanism is the only kind of inter-module linkage used. Since some of the functions in libnumarray are just there because they needed to be shared within the implementation, not exported as public interface, "everything" is never going to be documented. However, specific holes that people point out certainly can be. I'll document this one. Regards, Todd On Thu, 2003-10-23 at 20:48, Edward C. Jones wrote:
participants (2)
-
Edward C. Jones
-
Todd Miller