Do you mean views into structured arrays that only contain some of the original fields? (like a[['f0', 'f2']] = (1.0, 2.0)?)

I was working on a PR for this off and on, which is partly done. The goal is to allow writeable multi-field views, and to rework a bunch of the field assignment code (which has strange/buggy edge cases) in VOID_setitem and get_fields_transfer_function and related code.

I was going to sit on it until 1.10 is released to avoid cluttering the alpha/beta fixup process, but maybe that's not an issue.

Returning nonwritable views of subsets of structured arrays was originally scheduled for 1.9 to be followed by writable views in 1.10. Clearly, we are behind schedule ;) I had a PR for the views implemented, but a corner case test broke as missing items were filled in with spaces in the new dtype. I suspect the problem isn't fatal even if not fixable, but haven't gotten around to revisiting it.

Ah, yes, that's one of the corner cases I noticed too. There's a similar one where "unviewed" bytes get filled in with garbage. Here are demos of the one you mentioned, plus that one:

>>> a = np.array([( 1, 2),( 3, 4)], dtype=[('foo', 'i8'), ('bar', 'i8')])
>>> a[:] = np.array([(10,20),(30,40)], dtype=[('bar', 'i8'),('baz', 'i8')])
>>> a
array([(0, 10), (0, 30)], 
      dtype=[('foo', '<i8'), ('bar', '<i8')])

Other edge case:

>>> a = np.array([(1,2),(3,4)], dtype=[('foo', 'i8'), ('bar', 'i8')])
>>> b = a.view({'names': ['bar'], 'formats': ['i8'], 'offsets': [8]})
>>> b[:] = 4
>>> a
array([(139714726796880, 4), (139714726796880, 4)], 
      dtype=[('foo', '<i8'), ('bar', '<i8')])

Also, I don't like the current behavior that fields get assigned "by field name", and was hoping to be able to change it to assignment "by field position", if the back-compatibility break wasn't too bad (I suspect it might not be). That way assignment by structured scalars would behave the same as assignment using tuples (or equivalently, assignment using .item() on a structured scalar).

Probably a lot of my changes (which might turn out to be a bad idea in the end..) are othogonal to your PR for making the view writeable, so I'll keep thinking about them in the meantime.

I am interested in starting contributing to NumPy and I would like to start with this issue. Are you people working on it? If not actively, I can take this part to let you people focus on other important things.

Thoughts? Putting this in 1.11-release for the moment, but may move to 1.12.

Like discussed in #3641 (which is essentially the same issue?), a PR for this is #6053, but it's probably not ready for 1.11.

Oh, but one thing that we might consider adding to 1.11 is the deprecation warning for #6503, implemented in #6054. I guess that's conditional on whether #6503 is the right solution.

Let's just leave it for 1.12. That should branch in 3-4 months.