ENH: Make dtype iterable

[eric-wieser]

Now, iter(dtype) is the same as (d[i] for i in range(len(d))). This adds some consistency:

>>> v = np.array((1, 2, 3), dtype=[('a', int), ('b', float), ('c', str)])[()]   # get a void scalar
>>> v[0]
1
>>> list(v)
[1, 2.0, '']
>>> v.dtype[0]
dtype('int32')
>>> list(v)
TypeError: 'numpy.dtype' object is not iterable
# after this patch
[dtype('int32'), dtype('float64'), dtype('S0')]

Moved from #8814

One perhaps strange consequence:

>>> dt = np.dtype([('a', np.int8), ('b', np.float32, 3)])
>>> np.array(dt)
np.array(np.dtype([('a', 'i1'), ('b', '<f4', (3,))]), dtype=object)
# after this patch
np.array([('a', np.int8), ('b', np.float32, 3)], dtype=object)

[eric-wieser]

Hmm, actually this conflicts with #8615 - perhaps treating structured dtypes as dict-like is better than sequence-like.

[charris]

@seberg Thoughts?

[seberg]

Hmmm, I don't have a clear opinion. I lean slightly towards the ordered dict-like approach (which would mean closing this PR). In the end:

• I think the dict-like is how we want users to think about structured dtypes (and especially arrays) usually.
• But: for assignment when casting between different structured dtypes we explicitly use the field-order approach. So for (same-kind, not safe) casts, the order is actually more relevant than the field names.

So whichever choice it probably is a bit weird... There might be a point in refusing the choice, but adding the dict-like methods .keys(), .items(), and maybe .values(). We could add those only to the void dtype now in principle (maybe a bit awkward still, but should not be hard).