I'm not convinced that allowing promotion of void buffers is sensible - the void type is not null-terminated, so void("\0") and void("\0\0") are different things. If the user wants to null-pad their void data, they can use np.bytes_, either directly or by casting to void through `bytes..

Hmmpf, that is a good point. The reason for that change was to make the np.array call work because it currently (inexplicitly) does.

I guess I can make the coercion with np.array([b"a", b"ab"], dtype="V") just fail and we can probably get away with it. That sounds actually better to me from that perspective. Does that sound fair to you guys?

OK, I change it to that. We can briefly discuss this, but I think this is the reasonable thing to do. A bare dtype="V" should be very strange, and in fact there was a bug here that it went to object even though "V" was provided and nobody noticed yet, so it doesn't seem likely it affects any important downstream package (and I don't see how they could employ dtype="V" reasonably).

Can we raise an error message that indicates that null padding can be achieved by using bytes instead?

Not really, since this is a promotion error message you would need special handling just for void somewhere...

The code right now seems to give the error "invalid type promotion with structured or void datatype(s)". I'm suggesting we tailor that a bit for different types of void dtypes.

Or is your point that the error is swallowed?

Sorry, too much casting :(. For np.can_cast I can't raise a custom error, promotion currently indeed raises its own error and that seems fine (we are not likely to write if can promote_types(...)).

I added the error, it will also show up for other things (although probably not realistically).

I guess one thing we could think about is creating a PromotionTypeError if we ever run into the issue of wanting to be careful about it. In theory our comparison code does run into it. arr1 == arr2 has (or should have) a try/except around promotion and return an array of False if it fails.

Gentle ping, can we put this in?

Thanks @mattip, its not a big change and it is holding me up a bit, so I will squash merge it in a bit when the test ran through (undid a leftover change from the first version).