Fix #5339: cache dtype.__hash__.

Fix #5339: cache dtype.__hash__
Shouldn't adding a field at the end be fine, ABI-wise? We don't allow
subclassing. What cython issue are you thinking of?

I doubt there's any legitimate reason for anyone outside numpy to access
anything besides a few fields at the beginning anyway though (in
particularly itemsize), and I've also been pondering plans to rewrite the
dtype struct. So I wouldn't rule that out either. Rather than using a
pimpl, though, it might be sufficient to just hide the private fields
behind a private struct definition that only we can cast to.
On 4 Dec 2014 06:47, "Julian Taylor" <notifications@github.com> wrote:

> In numpy/core/include/numpy/ndarraytypes.h:
>
> > @@ -619,6 +620,10 @@ typedef struct _PyArray_Descr {
> >           * for NumPy 1.7.0.
> >           */
> >          NpyAuxData *c_metadata;
> > +        /* Cached hash value (-1 if not yet computed).
> > +         * This was added for NumPy 2.0.0.
> > +         */
> > +        npy_hash_t hash;
>
> this unfortunately breaks the ABI and causes forward compatibility issues
> with cython.
> though I am playing with breaking ABI by hiding the ufunc structure (at
> least partially) maybe we could break this too.
> But if we do we should do it properly and add a pointer to a private
> object or something similar.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/numpy/numpy/pull/5343/files#r21288459>.
>