-
-
Notifications
You must be signed in to change notification settings - Fork 10.9k
ENH: Show full PEP 457 argument lists for ufuncs #9026
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
If we want to make inspect.signature work, we'd:
It's worth noting that |
44c1506
to
a01b003
Compare
I now looked in a bit more detail, and this looks all good. It might make sense to have it in 1.13 still, but perhaps @charris should decide on that. |
@mhvk If you think it is good, put it in. The 1.13.0 milestone is for things I think need to be in 1.13, and some of those I'll probably push off again to 1.14. |
Note that if we do put this in, the arguments still wont be described on the individual ufunc pages - so somehow, we should probably link back to the ufunc docs |
@eric-wieser - you mean that these changes are visible in, say, ipython, but won't be seen by sphinx? |
I mean that the top of the sphinx page will list all the arguments, but nowhere on the page will a description of the arguments be given. Having said that, I haven't actually tested that sphinx supports this syntax... IPython seems to show the new longer argument lists, which was my main aim here |
And havehad difficulty in the past on windows getting numpy to build docs from the source, rather than the installed version |
Ah, yes, so the general description has to be adapted too. In that case, my suggestion would be to merge this with 1.14 as a milestone, and raise a new issue to also adjust the overall documentation. |
Huh? Do you mean wait until 1.13 is branched, and then merge? Or set the milestone to 1.14 yet merge it into 1.13? |
a01b003
to
bd3e35a
Compare
Done. All this needs is someone with a working doc build setup to check that the pages for |
Alternate array object(s) in which to put the result; if provided, it | ||
must have a same shape that the inputs broadcast to. | ||
where : array_like, optional | ||
Values of True indicate to calculate the ufunc at that position, values |
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 a bonus, this now means that where
is documented everywhere.
We could add the others here, but the explanations are more complicated, and they'd risk diverging from ufuncs.kwargs
def add_newdoc(place, name, doc): | ||
doc = textwrap.dedent(doc).strip() |
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.
dedenting here makes substituting $PARAMS
do the right thing
267b035
to
18f226d
Compare
where : array_like, optional | ||
Values of True indicate to calculate the ufunc at that position, values | ||
of False indicate to leave the value in the output alone. | ||
|
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.
To make it clearer that there are other arguments, I'd put this as part of the parameter list:
**kwargs
For other keyword-only ...
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.
Done
For reasons slightly beyond me, I have similar problems with the sphinx build using the system installation of numpy despite being in a virtual environment in which I have installed the PR. So, I cannot immediate check that things work there. Inside ipython, things look good, except I think one might as well adjust the class docstring as well... |
d21b48c
to
d0e2800
Compare
Done |
The solution I found is to use The signature works just fine, but the link doesn't work: Oddly, sphinx seems to move the square brackets around, but it doesn't seem to matter |
I think numpydoc doesn't like the link in the parameter list, as there
was no allowance in the spec for stuff after the parameter list.
.
The extra explanation can probably be put in a Notes section or so.
|
Arguments for putting this in 1.13: We're now allowing people to intercept all the ufunc arguments in |
I think you ended up making the full change, right? If so, I think 1.13 is indeed appropriate. |
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.
Had another look and found a few small things to change, but overall, this looks great!
numpy/add_newdocs.py
Outdated
@@ -5421,40 +5421,19 @@ def luf(lamdaexpr, *args, **kwargs): | |||
""" | |||
Functions that operate element by element on whole arrays. | |||
|
|||
To see the documentation for a specific ufunc, use np.info(). For | |||
example, np.info(np.sin). Because ufuncs are written in C | |||
To see the documentation for a specific ufunc, use `np.info`. For |
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 think this needs to be double ticks to, or does it link correctly? (I ask since in astropy this would require ~numpy.info
; if the link does work, maybe pre-pend :func:)
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.
Forgot to check this. I think you're probably right there.
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.
This page never gets generated anyway in the html docs, so this is kinda irrelevant
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.
Switched to info
for simplicity, in case this does get linked in future
def add_newdoc(place, name, doc): | ||
doc = textwrap.dedent(doc).strip() | ||
doc = doc.replace('$PARAMS', _params_text) |
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.
Bit odd to have this shell-like contruct. Why not just call it {PARAMS}
in the strings, and here do
doc = doc.format(PARAMS=_params_text)
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.
Latex in the docstrings was my concern here
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.
OK, that seems fair enough. Just leave as is, then.
@@ -3067,6 +3083,7 @@ def add_newdoc(place, name, doc): | |||
---------- | |||
x1 : array_like |
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.
Might as well change this to x
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.
Yep, since right now it doesn't actually match the injected signature
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.
Done
I think after #9063 makes most sense, but I'm changing the milestone so this won't be forgotten! |
This was covered by very few ufuncs, and is probably better to leave out.
ae1cfe5
to
1f3f57a
Compare
out : array_like | ||
An array to store the output. Must be the same shape as the | ||
output would have. | ||
*x : array_like |
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.
Each of the *
need escaping like so \\*
for sphinx. If you make it a raw string you can use a single \
.
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.
This file never actually reaches sphinx anyway, but I was under the impression that this worked correctly due to the transformation that the Parameters
section undergoes
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've had to fix other uses before as the docs didn't render correctly.
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.
Well, this doesn't even get rendered, so no danger of it getting rendered incorrectly!
Since the only place this is ever seen is in the terminal, I'd argue it's better without backslashes.
I'd also argue that to keep the terminal tidy, the fix should go in the numpy sphinx extension, not here
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 agree that having numpydoc escape the *
's when generating the sphinx input would be nice, but it doesn't at this time. If this never showed up in the documentation, that would not be a problem, but I assume you would like it to eventually show up.
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 I assume you would like it to eventually show up.
Not really - AFAICT, the sole purposed of this page is to redirect the user to np.info
or the ufunc docs. if ufunc.__doc__
is made visible in the web docs, then IMO, it should be the contents of ufuncs.rst
.
This docstring aside - I was pretty sure that **kwargs
was parsed correctly in the other docstring modified by this changeset - does the issue only exist for single asterisks?
numpy/add_newdocs.py
Outdated
where : array_like, optional | ||
Values of True indicate to calculate the ufunc at that position, values | ||
of False indicate to leave the value in the output alone. | ||
**kwargs : |
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.
Don't know if this needs something after the :
or not, but might be safer to put a placeholder there.
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.
That :
should probably be removed, but again - no HTML docs are generated from this page
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.
Irrelevant given that there are documents generated, but yes, with the : removed it works fine.
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.
Fixed, anyway
The distinction between unary and binary is not too helpful, and ignores the fact that trinary ufuncs can exist. Also add a link to the ufunc docs
1f3f57a
to
2e32026
Compare
Not sure. The |
Ok, see the screenshot in the above comment - the |
|
@mhvk: Do you have an example of *args working too, to save me the trouble of a local build? |
@charris: tested with unescaped Is this then good to merge? |
Looks like the escape problem has been fixed, good to know. Now we can clean up the other cases ;) |
Thanks Eric. |
Describes the full argument lists of
ufunc.__call__
using PEP 457 syntax.Before:
After:
In future, this could be hooked up to
__text_signature__
(#8734) to makeinspect.signature
work on ufuncs (right now, this requires monkey-patchinginspect
).This needs to be checked for compatibility against sphinx/numpydoc, which might choke on this signature formatDone and working!