We might not need to use NPY_LIST_PICKLE as when NumPy pickles a QuadPrecDType array:

• It saves the dtype (using our reduce) (QuadPrecDType, ('sleef',))
• It saves the shape
• It saves the data, PyArray_ToString returns raw 128-bit bytes

StringDType needs NPY_LIST_PICKLE because:

• Its memory contains pointers to Python strings
• PyArray_ToString would just copy worthless pointer values
• So it uses _getlist_pkl to extract actual string objects

Our QuadPrecDType stores actual numeric values in memory, so PyArray_ToString works perfectly

hash implementation might require some careful handling https://github.com/python/cpython/blob/20b69aac0d19a5e5358362410d9710887762f0e7/Python/pyhash.c#L87

I'll do this in a different PR and then we can close the #231

Why is the backend provided as an integer? A string literal might be a lot clearer, or if it has to be an int maybe we could add an int enum?

Why is the backend provided as an integer? A string literal might be a lot clearer, or if it has to be an int maybe we could add an int enum?

Internally backend is defined as enum, we provide the friendly API for the user to add input as string. For the sake of static tools, IDE suggestions I think defining as enum might make sense maybe @jorenham can give some inputs here

I suppose you could do Backend: typing.TypeAlias = typing.Literal[1, 2], or maybe even an enum.IntEnum