#17419, which deprecated the use of structured arrays composed of just a subarray, is causing a few problems in astropy (see astropy/astropy#10815). While these can be fixed with the suggestion made by @seberg, one of the fixes is not very nice: In our case, it turns out all problems are with np.array([], dtype=subarray), which means we have to special-case an empty list.

But I wonder if it doesn't make sense to try to move towards the case where

np.array(data, dtype)

always returns an array with the requested dtype, and for data=[] it would be equivalent to np.empty(0, dtype). Certainly, it is strange that the first of the following works but the second does not:

>>> import numpy as np
>>> np.array(([1, 2], 3), dtype='(2,)i,i')
array(([1, 2], 3), dtype=[('f0', '<i4', (2,)), ('f1', '<i4')])
>>> np.array(([1, 2],), dtype='(2,)i')
TypeError: int() argument must be a string, a bytes-like object or a number, not 'tuple'

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: setting an array element with a sequence.

Of course, I realize it is not easy to move from arguably mistaken behaviour to more logical one, but looking at our problem cases at least, I realize that in those we basically assumed the more logical one (i.e., they were bugs that somehow failed to get exposed)...

Concretely, I wonder if one could warn and move to more logical behaviour in one go (or give the option to use the more logical behaviour or so).