[Numpy-discussion] Tabular data package

Elaine Angelino elaine.angelino@gmail....
Tue Oct 6 08:33:38 CDT 2009


On Mon, Oct 5, 2009 at 7:20 PM, Robert Kern <robert.kern@gmail.com> wrote:

> On Mon, Oct 5, 2009 at 18:15, Elaine Angelino <elaine.angelino@gmail.com>
> 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-philosophy
).

Thanks for the help,

elaine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20091006/c2fad881/attachment-0001.html 


More information about the NumPy-Discussion mailing list