I would not say I know too much about these descriptors, but it seems right to add the void field at the end as well....

This sounds right to me, but maybe we should re-read the Array Interface docs and PEP-3118 to be sure.

Yes, those docs suggest this is the right fix. Consider:

>>> my_dtype = np.dtype({'names':['A', 'B'], 'formats':['f4', 'f4'], 
...                      'offsets': [0, 8], 'itemsize':16})
>>> a = np.ones(10, dtype=my_dtype)
>>> a.__array_interface__
{'data': (93829939730032, False),
 'descr': [('A', '<f4'), ('', '|V4'), ('B', '<f4')],
 'shape': (10,),
 'strides': None,
 'typestr': '|V16',
 'version': 3}

Note that typestr says there are 16 bytes, yet descr only describes 12 bytes. But in the Array Interface docs it says of descr, "The only requirement is that the number of bytes represented in the typestr key is the same as the total number of bytes represented here."

So we do need to add the void at the end.

Also __array_interface__ only has one dedicated unit test, the function test_array_interface. Maybe it makes sense to put your test next to that one, so further __array_interface__ tests can agglomerate there?

I just added a duplicate of the test there. While the behaviour is identical, no pain in just duplicating to make sure this stays identical even if it might some day be ripped apart.

LGTM. I will let this sit a few hours and then I'm happy to merge.

Also, for future reference I noticed that there is a test test_trailing_padding a little higher in that file, in the PEP3118 test. It tests for the ability of _dtype_from_pep3118 to convert a buffer spec with trailing padding bytes into a dtype. Not sure it always does the right thing because _dtype_from_pep3118('ixxxi') hides the padding but _dtype_from_pep3118('ixx') doesn't.

Anyway, that can be left for a later fix. Both descr and buffer specs need some attention, when converting them back to dtypes.

Merged. Thanks @seberg.