Why look up the method on the class rather than just getattr(marr, method_name, None)?

Seems tidier I guess (and closed to how dunder lookup works), and makes it work on masked record arrays.

You've actually made me notice a bug here, in that reversed should only apply to the method call. Either way, that bug was here all along, and can wait for another PR.

It does look really weird to me to look it up on the class! But of course if one looks up on marr, one cannot pass marr as first argument below. If I were to write this, I'd probably do:

method = getattr(marr, 'method_name', None)
if method is not None:
    return method(*args, **params)
else:
    return getattr(np, method_name)(marr, *args, **params)

Anyway, no big deal either way.

One could change MaskedArray.__new__, though perhaps calling a class constructor and not getting back a new instance might also be surprising... Perhaps best might have been to have had a logical distinction between the np.ma.MaskedArray class and a np.ma.masked_array/np.ma.array function...

Overall, this is probably the best solution.

One could change MaskedArray.__new__

This is the correct approach, and already how ndarray.__new__ behaves. Now take a look at MaskedArray.__new__, and tell me how easy that changes looks. That's why I'm calling this a workaround!

I think one would add right after the first line:

if _data is data and (type(_data) is cls or subok and isinstance(_data, cls)):
    return _data

Just to be sure: I think for a bug fix you're current approach is preferable!

@mhkv: Not enough. I think you also need to check that all of the other arguments are their default value, or more difficultly, compatible values

Yes, makes sense.

I think with your other change it is now safe (and shorter though a bit slower) to just do

compressed = _frommethod('compressed')

I agree. Until just now, I thought that this was only for methods that exist in np, but it is not

I'll add another commit for this that fixes a bunch of other methods as well, that were out of scope for the original PR

@mhvk: actually, can I bump that method cleanup to another PR?

Yes, better in another PR. As is, this is a bug fix, but that would be maintenance.

Happy for me to leave this line in then, or do you want me to remove it?

In another PR is slightly better, but really this is making work, so whatever you feel like!

I'd rather this just be merged as is, to be honest

No problem.