Unexpected compound datatype construction

When constructing compound types giving a tuple of tuples, instead of a list of tuples as is common in docs, leads to unexpected results.

Reproducing code example:

import numpy as np
print(np.__version__)
print()

dts = [
    [('int',int), ('float',float)],
    (('int',int), ('float',float))
]

for dt in dts:
    print(dt)
    print(np.dtype(dt))
    print(np.full(5, 10, dtype=dt))
    print()

On my system this is producing:

1.18.1 3.6.5 (default, Jun 17 2018, 12:13:06)
[GCC 4.2.1 Compatible Apple LLVM 9.1.0 (clang-902.0.39.2)]

[('int', <class 'int'>), ('float', <class 'float'>)]
[('int', '<i8'), ('float', '<f8')]
[(10, 10.) (10, 10.) (10, 10.) (10, 10.) (10, 10.)]

(('int', <class 'int'>), ('float', <class 'float'>))
int64
[10 10 10 10 10]```

[rossbar]

Thanks for the time spent chasing this down @seberg. An approach along the lines you proposed + additional tests seems like a good approach (+ some extra time for fully grokking the change to the logic 😃 ).

I’d also advocate adding an additional example to the doc string to highlight the “special” behavior of len-2 tuples for specifying dtypes.

[seberg]

I think we should do that. Not limiting user datatypes would be possible, but I am currently not sure what the point of an int64 + fields is. You are going to lose that extra informtion in ufuncs, etc. anyway typically. So it seems to me that basic view or a maybe a new union dtype/structured dtype with overlapping fields makes more sense. In other words: Rather than not restricting user dtypes as I did above, I would prefer to think about deprecating the whole thing unless someone finds a good use-case. It seems way too smart to me.