BUG: construct ma.array from np.array which contains padding - #7788

Nice catch!

I think this we can get this merged without too much more effort, but I have two suggestions to consider first:

First, the same type of fix may be needed a few lines down (line 426) for _recursive_set_fill_value.

Second, maybe instead of patching descr we can refactor _recursive_set_default_fill_value and _recursive_set_fill_value to avoid use of dtype.descr entirely. In my opinion none of the MaskedArray code should touch the dtype.descr attribute, since as I understand it is only meant to be used in the "PEP3118 buffer interface" and because of that converts the padding in a funny way. It would be better to only use the dtype.names and dtype.fields attributes. For example, I imagine _recursive_set_fill_value could look like

def _recursive_set_fill_value(fillvalue, dtype):
    fillvalue = np.resize(fillvalue, len(dtype.names))
    output_value = []
    for (fval, name) in zip(fillvalue, dtype.names):
        cdtype = dtype[name]
        if cdtype.names:
            output_value.append(tuple(_recursive_set_fill_value(fval, cdtype)))
        else:
            output_value.append(np.array(fval, dtype=cdtype).item())
    return tuple(output_value)

and have fill_value = np.array(_recursive_set_default_fill_value(ndtype), dtype=ndtype). (I haven't tested that code). That way we don't even need to think about the padding bytes in descr.

A similar change would be needed for _recursive_set_default_fill_value. Does that seem reasonable?

@ahaldane What you say sounds reasonable. I'm not volunteering to do it, but it did strike me that using descr there is unfortunate.

Sidebar: I was surprised to see this code was called even if I passed a fill_value argument to ma.array().

OK, in that case I took a shot at removing use of descr in #7790. I copied your test, too.

Is that all right?

Closing in favor of #7790. Thanks @ahaldane .

Thanks for finding the bug and identifying the problem code @jzwinck !