[Numpy-discussion] Custom dtypes without C -- or, a standard ndarray-like type

Eric Moore ewm at redtetrahedron.org
Tue Sep 23 07:40:23 EDT 2014


On Tuesday, September 23, 2014, Todd <toddrjen at gmail.com> wrote:

> On Mon, Sep 22, 2014 at 5:31 AM, Nathaniel Smith <njs at pobox.com
> <javascript:_e(%7B%7D,'cvml','njs at pobox.com');>> wrote:
>
>> On Sun, Sep 21, 2014 at 7:50 PM, Stephan Hoyer <shoyer at gmail.com
>> <javascript:_e(%7B%7D,'cvml','shoyer at gmail.com');>> wrote:
>>  My feeling though is that in most of the cases you mention,
>> implementing a new array-like type is huge overkill. ndarray's
>> interface is vast and reimplementing even 90% of it is a huge effort.
>> For most of the cases that people seem to run into in practice, the
>> solution is to enhance numpy's dtype interface so that it's possible
>> for mere mortals to implement new dtypes, e.g. by just subclassing
>> np.dtype. This is totally doable and would enable a ton of
>> awesomeness, but it requires someone with the time to sit down and
>> work on it, and no-one has volunteered yet. Unfortunately it does
>> require hacking on C code though.
>>
>
> I'm unclear about the last sentence.  Do you mean "improving the dtype
> system will require hacking on C code" or "even if we improve the dtype
> system dtypes will still have to be written in C"?
>

What ends up making this hard is every place numpy does anything with a
dtype needs at least audited and probably changed. All of that is in c
right now, and most of it would likely still be after the fact, simply
because the rest of numpy is in c. Improving the dtype system requires
working on c code.

Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20140923/b20be5bf/attachment.html>


More information about the NumPy-Discussion mailing list