Check structured dtypes separately for byteorder preservation - #11545

Please rebase to fix the importlib_metadata issue.

The cron will take a while, but I assure you they will complete at some point. 😅

Thanks for getting the weekly cron started; I had no idea how to set that off.
Yes; and I thought it was slow when it was on for 80 minutes last night without actually running any tests!

I could still change the else case to original = m.info.dtype.newbyteorder('='); I don't remember why I originally picked original = m.info.dtype.name, but for any dtypes it understands it should be functionally equivalent.

If it works with original = m.info.dtype.newbyteorder('='), I think it would be better; otherwise we're only checking that the dtype remains a void with the right length.

Oops, of course void now doesn't go to that branch any more. The only advantage of newbyteorder is then that it is a bit more explicit.

Oops, of course void now doesn't go to that branch any more. The only advantage of newbyteorder is then that it is a bit more explicit.

Yes; I thought there were some corner cases were i4 and <i4 for some reason did not evaluate equal (on a LE machine), or perhaps some of the Int types... but since your PR passed on all other CIs that seems to be just as valid.

Oops, do we need another run of Weekly CI?

do we need another run of Weekly CI?

Yes, given that this patch fixes something that we only see in one of the "exotic" archs.

Yes, given that this patch fixes something that we only see in one of the "exotic" archs.

With the extra big-endian version of ndarray it should show up on the other archs now, too; but again, I might have selected dtype.name because there were even more exotic phenomena popping up.

There is no harm to wait for the full report anyway, just in case. You can check again when you wake up tomorrow. 😉

It is not that late here, especially not for me – but judging from the runtime this seemed a relatively scarce resource. 😝

Thanks for reviewing!