Fix #5339: cache dtype.__hash__.

Fix #5339: cache dtype.__hash__
I hope no-one is embedding this struct into a larger one, b/c that's going
to be broken no matter what. I guess they might be able to get away with it
ATM because dtypes don't actually support GC traversal, but this is a bug
-- dtypes can participate in reference loops! (for example
dtype->subarray->base is a pointer to a dtype). And any type supporting GC
*must* have all instances allocated via PyObject_GC_New, b/c this allocates
some extra memory at a known offset where the GC will scribble bookkeeping
information during its traversal. If you try to stick a GC-supporting type
into another struct or something anything like that, then the GC will end
up scribbling on random memory.

So I'm not too worried about breaking code that does that. It'll be broken
sooner or later regardless.

And I concur that the cython thing is just an annoyance. Probably we should
ask them to get rid of it.

I don't recall any reports of brokenness after the 1.7 release, which was
the last time we increased the size of dtype instances.

We should talk more about dtype rejiggering but probably this is not the
right thread for that discussion :-)

On Thu, Dec 4, 2014 at 2:36 PM, 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;
>
> I haven't finished my ufunc patch yet, though it goes along the lines that
> njsmith suggested, keep the current structure and internally use a larger
> one. Additionally it might be interesting to mangle the public part in the
> development version to trigger failures for people that use the internals.
> For release the mangling can be reverted.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/numpy/numpy/pull/5343/files#r21306949>.
>



-- 
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org