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
Output of help(...) is wider than 80 characters #53948
Comments
In several modules, the output of help(some_module) is wider than 80 characters. This results in extra line wrapping and incorrect formatting of the help text. I've attached a single patch (doc_width1.diff) that corrects the issue for math, cmath, tuple, datetime, and time modules. I can continue to create patches for a few modules at a time, or I can create patches for individual modules. I'm not changing any text, only adding \n as needed. |
Aren't there tools that extract only the first line of help? |
According to PEP-7, the first line of the doc string should contain the signature of the function, then there should be a blank line, and then the rest of the doc string. There may be tools that extract the signature line. The patch just decreases the line length of the remaining lines of the doc string so they don't wrap when displayed on an 80 character wide terminal window. For an example, look at the text for modf(...) in help(math). I just noticed that the math module uses "modf(x)" for the signature line but PEP-7 recommends including the return type, say "modf(x) -> (frac, int)". The simplest change would be to fix the wrapping issue and leave the signature line alone. It would be more effort to make all the doc strings PEP-7 compliant by standardizing the signature line to include the return type. I'm willing to work through the standard library and create patches for either option. |
Although this is not a problem in IDLE where the window can easily be expanded beyond 80 chars, I am in favor of the idea for other uses. The command line interpreter on Windows defaults to 80 chars and is not so easy to change, and one must be admin to make the change 'permanent' (until the next install reverts the change). In particular, the 82 char line for math.trun results in 'd.' of 'method.' wrapped to a line by itself with no indent. Pretty ugly. However, I am puzzled why you edited the 74 char line for math.modf, which displays as 78 chars with a 4 char indent. This I agree that For something like I personally think '->' and 'return are redundant, so I would argue that this could be shortened to Since I am not yet in a position to apply patches, I am not (yet) in a position to tell you whether or how to produce more patches. |
I edited the doc string for math.modf since an indent of 8 spaces is used for the doc string with help(math). An indent of 4 spaces is used with help(math.modf). I've attached a new patch for just the math module that includes the return type as part of signature line, corrects the width issues, and uses a consistent format for defining the doc strings. |
@terry is this something you could take on? |
Perhaps after the Google Summer of Code project is done (mid-August). |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: