-
-
Notifications
You must be signed in to change notification settings - Fork 480
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
Add small examples of common docstring styles #38117
Conversation
Documentation preview for this PR (built with commit f4cb7cb; changes) is ready! 🎉 |
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. Looks good.
Thanks. A good example of collaborative work :-) |
Let's give this a bit more time. @saraedum we can continue the discussion here. |
OK. We can. If we reach to a consensus that we can implement, then we can make a new PR.
I am too. There is no rule in sage community to decide what is a rule :-)
I agree with this.
Of course, since most default values are
I agree. The problem is that there are examples for each of different styles.
I would not say that any of (A)
(B)
(C)
does not follow a rule. It all depends on the author's intention about the python function he is writing. If the value has no mathematical meaning, (A) is okay. If the value is a python object, (B) is the only choice. If the value is mathematical, then (C) is nice. If the function calculates an arc length of an ellipse and takes input a and b which are radians, the default values of a and b are mathematical, then clearly (C) is preferable. In this example,
we want to say (C) is recommended. |
No, that's not what I meant. Sorry, I should have been more specific. I grepped for numerical values only here. Even with just integers, I get:
|
People have varying preferences in SageMath and we do not enforce any particular code style. I don't think this is a huge problem but I remember that it's confusing when you are working on your first contributions that it's a bit unclear which example to follow.
Actually, in my REPL this does not work reliably. For functions I see the signature with
That's probably a separate problem. If the signature were always shown with the docstring, then I don't think it's so important to spell out the defaults in that technical form.
I see your point here. I had another look at the documentation, and arguably Ideally, limitations in the renderer should not inform how we write docstrings but I remember that in Wikipedia there were similar rules about not using LaTeX for something simple like a 1 since it changes the font and breaks the flow for the reader. From that perspective, a simple plain |
Your argumentation about simple values not being LaTeXed sounds good to me. Indeed it is ugly otherwise. Maybe we should add a guiding example for every usual scenario. What about strings for example? A) string, B) "string", C) |
It works with |
I fully agree.
Unfortunately, cython method does not always show the signature. This is an old issue: #26254 In this regard, there is subtle difference between our definitions of "default value". For me, default value is the value that the function assumes for an input when the user does not give a specific value. On the other hand, the default value in the function signature is always a python object (code), as you said. In my view, the former default value is what the latter default value represents when it is mathematical.
Perhaps yes. But we are writing math If there is not much math in the function or that 1 and other integers are only values, then simple 1 is preferable. This is all what the author should decide. We cannot recommend one style unilaterally. |
is what @mkoeppe writes (in his extensive work on cleaning doctests). I fully agree with this style. |
Recently I saw
I think this is perfectly okay. This is a good example where the default value is not the literal value in the function signature. |
I propose the addition of a line such as
The 1 or `1` point is somewhat subtle. Can we maybe leave it at `1` for consistency (because it is something mathematical) and have a LaTeX rule or package ( |
OK. I will do it.
If you mean to do nothing about existing instances of 1 or 0 as default values, I do agree. As it is subtle, they should be treated case by case.
We don't do that when we write a paper. There "1" is usually math and written |
Done. |
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.
<!-- ^ Please provide a concise and informative title. --> <!-- ^ Don't put issue numbers in the title, do this in the PR description below. --> <!-- ^ For example, instead of "Fixes sagemath#12345" use "Introduce new method to calculate 1 + 2". --> <!-- v Describe your changes below in detail. --> <!-- v Why is this change required? What problem does it solve? --> <!-- v If this PR resolves an open issue, please link to it here. For example, "Fixes sagemath#12345". --> which I think are already established. But it is good to recommend preferred styles to keep docstrings in consistent styles. motivated by the comment: sagemath#37821 (comment) ### 📝 Checklist <!-- Put an `x` in all the boxes that apply. --> - [x] The title is concise and informative. - [x] The description explains in detail what this PR is about. - [ ] I have linked a relevant issue or discussion. - [ ] I have created tests covering the changes. - [x] I have updated the documentation and checked the documentation preview. ### ⌛ Dependencies <!-- List all open PRs that this PR logically depends on. For example, --> <!-- - sagemath#12345: short description why this is a dependency --> <!-- - sagemath#34567: ... --> sagemath#38068 (merged here) URL: sagemath#38117 Reported by: Kwankyu Lee Reviewer(s): gmou3, Kwankyu Lee
<!-- ^ Please provide a concise and informative title. --> <!-- ^ Don't put issue numbers in the title, do this in the PR description below. --> <!-- ^ For example, instead of "Fixes sagemath#12345" use "Introduce new method to calculate 1 + 2". --> <!-- v Describe your changes below in detail. --> <!-- v Why is this change required? What problem does it solve? --> <!-- v If this PR resolves an open issue, please link to it here. For example, "Fixes sagemath#12345". --> which I think are already established. But it is good to recommend preferred styles to keep docstrings in consistent styles. motivated by the comment: sagemath#37821 (comment) ### 📝 Checklist <!-- Put an `x` in all the boxes that apply. --> - [x] The title is concise and informative. - [x] The description explains in detail what this PR is about. - [ ] I have linked a relevant issue or discussion. - [ ] I have created tests covering the changes. - [x] I have updated the documentation and checked the documentation preview. ### ⌛ Dependencies <!-- List all open PRs that this PR logically depends on. For example, --> <!-- - sagemath#12345: short description why this is a dependency --> <!-- - sagemath#34567: ... --> sagemath#38068 (merged here) URL: sagemath#38117 Reported by: Kwankyu Lee Reviewer(s): gmou3, Kwankyu Lee
which I think are already established. But it is good to recommend preferred styles to keep docstrings in consistent styles.
motivated by the comment: #37821 (comment)
📝 Checklist
⌛ Dependencies
#38068 (merged here)