MAINT,BUG,DOC: Fix errors in _add_newdocs #13876
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.
Fixes pymc-devs/pymc#3340, sympy/sympy#16556, and probably some others.
There was a problem hiding this comment.
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.
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.
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.
np.add_newdoc is public API, I think your suggestion will break that.
There was a problem hiding this comment.
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.
... but not really relevant to this PR
There was a problem hiding this comment.
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.
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.