-
-
Notifications
You must be signed in to change notification settings - Fork 10.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DOC: Fix bad reference in numpy.ma
#16300
Conversation
numpy.ma
numpy.ma
close/reopen |
numpy.ma
numpy.ma
Quick question @takanori-pskq - you've marked this as WIP: does that mean that it is not ready for review in your opinion? Also note that you don't have to fix all of the issues in #13114 in one big PR - in fact it would be preferable (from a review standpoint) if changes were broken up into smaller PRs that deal with coherent portions of the documentation. It seems this is how you originally intended to organize this PR (limiting changes to |
numpy.ma
numpy.ma
@takanori-pskq now that #16296 and #16311 are merged, do you want to try to rebase on master and see if that fixes the CI? I'd be happy to take a look afterwards! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for taking a stab at this @takanori-pskq , this is certainly an improvement in fixing up the broken links in np.ma
: I recorded 806 before this change (on 19f91f) and 738 afterwards. I think many of the changes are non-controversial. However, there is one pattern where numpy.
is prepended to functions in the numpy docstrings so that links in the corresponding numpy.ma
docstrings resolve to the numpy versions. This is okay, but has the unfortunate side-effect of cluttering up the original numpy docstrings a bit. Do you think there might be another way to get those links resolved using a different approach?
This PR touches a lot of different things so it will take me few passes before I can wrap my head around everything - I hope you can bear with me!
@rossbar Instead of just copying docstrings from numpy versions, how about writing the docstrings of the functions in |
I tend to agree in principle, but I don't think that this is a general solution. While some functions in Nevertheless, there are some changes in this PR that do indeed correct some broken links without affecting existing docstrings in other namespaces. Perhaps we could separate those out from the others that might need a more detailed discussion? If you're interested in doing so I'd be happy to help try to ID the straight-forward changes. |
I'll separate the changes prepending |
I think that's a good place to start. The addition of the missing functions to the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM - fixes about 25 broken xrefs in the ma docs (794 link warnings before, 769 after this change).
It seems this exposes new functions, should they have tests (maybe they already do)? |
Good point - AFAICT, the related creation functions that are already exposed in np.ma (e.g. |
rebased, and added tests for some functions. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple comments about the tests that have been added, but everything else LGTM
rebased and fixed the tests. |
There are a few comments open about shuffling tests around. @takanori-pskq would you like to relate to them or should we put this in as-is and somehow mark that for a later refactoring? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple suggested cleanups to the tests but otherwise LGTM!
Subsequent changes and discussion since initial approval
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As it stands, the newly-exposed zeros_like
, ones_like
, and full_like
functions won't support some of the masked array parameters (e.g. fill_value
, hardmask
). I think this is okay as empty_like
, which is already exposed, doesn't either. I'm fine with following the precedent set by empty_like
and leaving any potential updates to parameter support for the *_like
arguments for a future PR.
Everything else LGTM, thanks @takanori-pskq for taking the time to re-organize the tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was looking at this a bit more closely and just noticed an unfortunate name collision in the argument names of np.ma.full
: fill_value
is the name for both the value that full
uses to fill the array, and the fill_value
of the mask. In combination with _convert2ma
, this can result in nasty errors:
>>> np.ma.full(3, fill_value=5)
Traceback (most recent call last)
...
TypeError: full() missing 1 required positional argument: 'fill_value'
There might be a way around this using position-only arguments, but unfortunately I don't think the _convert2ma
machinery is sufficient to handle this, at least not in it's current form.
Parameter name collision between non-ma and ma versions of full
Can we merge this PR as-is and continue cleanup afterwards or is there still work that needs to be done here? When we merge it, we should re-open gh-13114 since this is marked as closing it, or is there a way to tell github not to close it on merge |
I think @rossbar's concerns are valid - this PR mixes two things:
The second point needs more work, and looks problematic in its current form. |
FYI, the the new |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good: 410 -> 397 warnings. Thanks @takanori-pskq !
Partly fixes #13114