-
-
Notifications
You must be signed in to change notification settings - Fork 11.1k
MAINT,BUG,DOC: Fix errors in _add_newdocs #13876
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
Conversation
5380585
to
c6e69fc
Compare
…hon 3 Avoid using `_add_newdocs` if these functions do not exist. Leaving the version-checking here so that we can backport to 1.16
This must have been lost in the multiarray / umath merge. Found by noticing that `add_newdocs` was being called on an object that does not exist.
`ndarray._as_parameter_` is not a real thing
This caught us trying to document members that don't exist.
c6e69fc
to
8b8952c
Compare
@@ -15,7 +16,7 @@ | |||
from numpy.core._multiarray_umath import * | |||
from numpy.core._multiarray_umath import ( | |||
_fastCopyAndTranspose, _flagdict, _insert, _reconstruct, _vec_string, | |||
_ARRAY_API, _monotonicity | |||
_ARRAY_API, _monotonicity, _get_ndarray_c_version |
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.
Fixes pymc-devs/pymc#3340, sympy/sympy#16556, and probably some others.
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.
The name begins with a '_', shouldn't we be discouraging its use rather than adding more private methods to the public API?
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.
Perhaps, but removing it from the API broke downstream packages, and I don't think it was a deliberate choice.
Also, this member is even documented, so I think is intended to be "public but only for library use" or something.
Hmm, I see that you dealt with potential back compatibility problems, so that's good. The new functions and |
I think adding full docstrings for the internal functions is probably not a good use of time or vertical space. Note that |
If a function has arguments, they need to be documented. And tell me about vertical space again :) |
numpy/core/_add_newdocs.py
Outdated
from numpy.core import numerictypes as _numerictypes | ||
from numpy.core import dtype | ||
from numpy.core.function_base import add_newdoc | ||
from numpy.core.function_base import add_newdoc as _add_newdoc |
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.
Rather than changing the name on import, could you change function_base.add_newdoc
to function_base._add_newdoc
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.
np.add_newdoc
is public API, I think your suggestion will break that.
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 see. What a mess: there is numpy.core.function_base
and numpy.lib.function_base
, each adds different things to __all__
.
Since the implementation is specific to the _multiarray_umath
module, why should add_newdoc
be part of the public API? Its only use is at startup to modify the uninitialized tp_doc
slot in _multiarray_umath
methods.
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.
... but not really relevant to this PR
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 don't think np.add_newdoc
should be public, but as a bugfix this PR tries not to break the status quo and leaves it where it is.
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.
Either way, evidently changing add_newdocs
is a can of worms, so let's not mix it with the bug fixes in this patch.
8b8952c
to
b592e8f
Compare
I rolled back the last commit in this patch set, because I think most of the comments were directed at it, and it's also the least useful commit to backport |
I'm going to claim immunity from this until the follow-up PR, since now this one doesn't add any new arguments or non-trivial functions :) |
reopening to trigger shippable rebuild |
Strange, I manually restarted the Shippable build to see if that helps |
Shippable seems to be working now, thanks @eric-wieser |
I'll spin off some backport PRs tonight, and resubmit the removed commit from this PR |
This reverts commit 7ac7fa9.
…-python MAINT: Revert #13876, "MAINT,BUG,DOC: Fix errors in _add_newdocs"
Hi all, I am trying work through this: with a '_get_ndarray_c_version' error. Suggestions? |
@PerryGrossman why did you add that comment to this issue? Please open a new issue if you think numpy is at fault here, and follow the instructions vis-a-vis reporting python and numpy configuration. A stacktrace would also be helpful. |
Intended to be backported to 1.16.x and 1.17.x - at the very least, the first two commits, but doing the whole patch-set is probably fine too.
Brought on by noticing some mistakes in gh-13847 that we'd ideally detect at build time.