On Tuesday, September 23, 2014, Todd <toddr...@gmail.com> wrote: > On Mon, Sep 22, 2014 at 5:31 AM, Nathaniel Smith <n...@pobox.com > <javascript:_e(%7B%7D,'cvml','n...@pobox.com');>> wrote: > >> On Sun, Sep 21, 2014 at 7:50 PM, Stephan Hoyer <sho...@gmail.com >> <javascript:_e(%7B%7D,'cvml','sho...@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
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
