On Mon, Oct 5, 2009 at 7:20 PM, Robert Kern
On Mon, Oct 5, 2009 at 18:15, Elaine Angelino
wrote: Then I would suggest making tabarrays subclass from ndarray.
Ok, done. We did it using the from*() function design you suggested. In the future, if there are more direct from*() functions working directly on ndarrays we'd want to switch to those of course. While implementing the change, we were reminded of another difference between ndarray and recarray, namely that the constructor of ndarray doesn't accept "names" or "formats" parameters while the recarray constructor does (e.g. you have to specify `dtype` in the ndarray constructor). This feature of the recarray constructor was useful for our purposes, since one of the goals of tabular is providing 'easy' construction methods. We've retained this feature, even though we've switched to subclassing ndarray. There must be a good reason why ndarray does not accept "names" or "formats" parameters and forces the use of the more explicit and unambiguous "dtype". I guess it's "cleaner" in some sense, since the formats parameter is necessarily more limited. It does make sense to have a strongly unambiguous interface for a cornerstone method like np.ndarray.__new__. That said, I think it also makes sense to have more flexible interfaces too, even if they're sometimes more ambiguous (this is part of the purpose of tabular, see http://www.parsemydata.com/tabular/reference/organization.html#design-philos... ). Thanks for the help, elaine