ENH: Add new numpy.ma.* aliases - #21998

@rossbar - I don't have a specific need for these, was doing issue and PR triage. If the decision is to not extend then we should go back and tell it to multiple PR authors, and close off issues, too so people know that there is a decision.

OTOH, a solution for broken links should be figured out, too, it's not OK to keep them around broken because the actual underlying code is not supposed to contain functionality that is linked to, but that is a separate, and maybe already fixed issue.

If the decision is to not extend then we should go back and tell it to multiple PR authors, and close off issues, too so people know that there is a decision.

Yeah I just want to make sure that the motivation for this particular case makes sense. I don't want to imply that we shouldn't add any new functions to np.ma. If it's just broken links in the docs in this case, it might be better just to switch the link targets to their non-ma counterparts. I'm not sure what the protocol is for adding ma versions of core functions... usually we encourage pinging the mailing list for API additions, but maybe not in this case? Thoughts @mattip @charris ?

OTOH, a solution for broken links should be figured out, too, it's not OK to keep them around broken because the actual underlying code is not supposed to contain functionality that is linked to, but that is a separate, and maybe already fixed issue.

Agreed, IIRC this is an unpleasant side-effect of the docstring munging in the _convert2ma class. There may be a documentation-specific solution involving modifying this class that might fix even more broken links in the ma docs.

My sole motivation was to wrap up almost ready PRs, e.g. #17480 which needed a rebase to pick up new CI and resolve conflicts, but otherwise was ready to go, based on the comments. Another similar one is #17500 which was separated out from #17480.

Note that I've already closed #17480 as it was conflicting, some of the aliases have been already been added, but basically, this one and #17500 have to go hand in hand, either close both as unwanted puppies/extensions of np.ma (absolutely valid decision) or merge them sometimes in the near future.

I am inclined to close this and not merge it until there is a clear use case for these functions. Is there anyone who is championing the additions and can point to their use-case for them?

I am inclined to close this and not merge it until there is a clear use case for these functions. Is there anyone who is championing the additions and can point to their use-case for them?

@mattip Shall we ask on the mailing list?

I started a mailing list discussion

Thanks @bsipocz. The mailing list did not bring up any use cases, so let's close this and try to fix the documentation in a different way.

Thanks @mattip. I suppose then the same logic applies to #17500 and we should close that one, too.