<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><span style="font-family:Arial,Helvetica,sans-serif">On Tue, Mar 24, 2020 at 12:12 PM Matti Picus <<a href="mailto:matti.picus@gmail.com">matti.picus@gmail.com</a>> wrote:</span><br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br>
On 24/3/20 11:48 am, Francesc Alted wrote:<br>
><br>
> What I am trying to say is that NumPy should be rather agnostic about <br>
> providing data types beyond the relatively simple set that already <br>
> supports.  I am suggesting that focusing on providing a way to allow <br>
> the storage (not only in-memory, but also persisted arrays via <br>
> .npy/.npz files) of user-defined data types (or any other kind of <br>
> metadata)  and let 3rd party libraries use this machinery to <br>
> serialize/deserialize them might be a better use of resources.<br>
><br>
> ...<br>
> Cheers,<br>
> Francesc<br>
><br>
I agree that the goal is to enable user-defined data types, and even <br>
make the creation of them from python possible (with some caveats about <br>
performance). But I think this should be done in steps, and as the <br>
subject line says this is the first step. There are many scary details <br>
to work out around the problems of promotion and casting, what to do <br>
when the output might overflow, how to mark missing values and more. The <br>
question at hand is, as I understand it, one of finding the right way to <br>
create a data type object that will enable exactly what you propose. I <br>
think this is the correct path, as most large refactor-in-one-step <br>
efforts I have seem leave both the old code and the new code in an <br>
unusable state for years until the bugs are worked out.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Thanks Matti for clarifying the goals of the NEP; having the sentence "New Datatype System" in the title sounded scary to my ears indeed, and I share your concerns about new code largely undergoing 'beta' stage for long time.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Before shutting up, I'll just reiterate that providing pretty shallow machinery for allowing the integration with user-defined data types should avoid big headaches: the simpler, the better.  But this is of course up to the maintainers.</div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
<br>
As for serialization protocols: I think that is a separate issue. We <br>
already have the npy/npz protocol, PEP3118 buffer protocol, and the <br>
pickle 5 buffering protocol. Each of them handle user-defined data types <br>
in different ways, with differing amounts of success.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Yup, I forgot the buffer protocol an pickle 5.  Thanks for reminder.</div></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Cheers,</div></div>-- <br><div dir="ltr" class="gmail_signature">Francesc Alted</div></div>