This is unnecessary because a cached hash value should not be computed yet for obj

But doesn't setting the cached value to -1 indicate that the has value is not cached? While a hash value of 0 (the default alloc strategy), would be taken as-is?

Simply removing it seems incorrect, e.g. try something like:

a = np.array([b"12345678901234567890"])[()]
assert hash(a) == hash(b"12345678901234567890")

I suspect that this change will mean we get 0 for hash(a)?

I am wondering if Python should not add a custom alloc function for bytes that sets the hash to -1 (so long as the fields still exists at all). As for NumPy, assuming Python ensures that the hash is invalidated on new versions, we need a version #if` directive to keep setting it to -1 on older versions.

xref python/cpython#91686 to add a custom tp_alloc for bytes, which makes this PR the right way to move forward.

The upstream fix to have a tp_alloc was merged. NEP 29 does not require we support python 3.11 on NumPy 1.22, but this seems like a simple fix to backport to 1.22.4. @charris should we backport it or only target 1.23 with this?

Thanks @felixxm. I will let @charris add the correct backport milestone, if any

@mattip Thanks for merging 🎊

Seems pretty harmless to backport, although I suspect it won't matter much as we won't release 1.22.x wheels for 3.11.