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
pydoc help (or help('help')) should show the doc for help #57900
Comments
What follows is a copy-paste of a shell session. Notice that at the end, rather than being inside the online help utility, I'm still in the interactive interpreter. I was able to duplicate this on python3.2, python2.7, and python2.6 (verifying it on other versions would have required installing them). Reading the source in trunk, there is nothing that looks like it actually should run this interactive help session. It's just missing. I guess nobody used this, eh? I've attached a patch that should fix it. I'm not sure how you want to handle adding a test for this, so please advise me on that. -----
Welcome to Python 3.2! This is the online help utility. If this is your first time using Python, you should definitely check out Enter the name of any module, keyword, or topic to get help on writing To get a list of available modules, keywords, or topics, type "modules",
|
IMO, help('help') should document the help function, not start an interactive help session (that’d be help()). |
I agree. It should explain the three options: help(help) prints unhelpful class _Helper(builtins.object)
| Define the builtin 'help'.
| This is a wrapper around pydoc.help (with a twist).
|
| Methods defined here:
...
"
which says not at all how to use help(). I have the feeling that there is a related issue on the tracker, but searching for 'help', 'help()', or 'help(help)' all return 620 hits. |
Ahhh, that explains it. help('help') isn't ever meant to be called; it's supposed to be: >>> help()
...
help> help
... the call to "help" at the help> prompt is equivalent to help('help'). help('help') should do something different, such as say how to use the help function, as you say. Whereas "help> help" makes sense. |
I’m interested in this, so I’m taking assignment. If a contributor is interested in making a patch I’ll review it, otherwise I’ll say when I start on a patch. |
I am working on it |
Just a heads-up: I’ll be offline between January 19 and the end of the month, so don’t worry if you make a patch and it’s not reviewed immediately (at least not by me, other developers may do it :) |
Is anyone still working on this? If not I would like to make this work. |
It doesn't look like anyone is working on it currently. Yes, getting this right is a bit tricky for exactly the reason you say. You have to make sure you don't break the other uses, and glancing at the patch (I haven't looked at the code you are patching) it seems likely that the change to the if statement is going to break *something*. Probably what happens when you type 'help' at the 'help>' prompt, at a guess. |
Help at the help> prompt does work, I tested that. But if you (or anyone) thought of a better way to fix this issue I would be glad to change it. |
"works" in the sense that it produces output. But it doesn't produce the output it used to, which is the same text as the initial banner when you type help(). I believe the existing behavior in this case is correct. With your patch it produces the same output as "help('help')" at the python prompt does, and what that output describes doesn't work at the 'help>' prompt. Thanks for tackling this. Hmm. How about adding the special case to _Helper.__call__? |
Oh, that wouldn't fix 'pydoc help', would it. So there are probably two places where the special case has to be added, which means the code itself should go in pydoc and be called from _Helper.__call__ somehow. (Note, I'm just throwing out ideas here, I haven't looked carefully at the code.) |
I see. So calling help('help') should produce the documentation on the help() function and typing help at the help> prompt should print the help for the prompt. |
I imported this patch on 3.4 and it worked as expected on my system. help('help') brings up info about help() |
What about "pydoc help"? |
$ ./python -m pydoc help Help on built-in function help: help(...)
Invoke the built-in help system.
help()
The interactive help system starts on the interpreter
console.
help(string)
The string is looked up as the name of a module, function, class, method,
keyword, or documentation topic, and a help page is printed on the
console.
help(object)
Generates a help page on the given object. Or did you mean inside the interpreter? |
Cool! Can you add tests? |
Nope, I can't add tests. |
I was addressing the author of the patch :) |
I just tested this issue in Python 3.6.0a0 and got this behavior: help('help') brings "Help on _Helper in module _sitebuiltins object:" help(help) brings: help() invokes the help command line. So this was fixes on the way to python3.6, I can make the test for 3.4 but is 3.4 closed for bug fixing? Can someone check this in 3.5? |
3.5 is the same as 3.6 in that now both help(help) and help('help') show the not terribly helpful "Help on _Helper in module site object:...". Buried in the text is As before, I think the _Helpter stuff should be eliminated and There has been this improvement
>>> help('jslfjslfdjlskfj') # 3.4
no Python documentation found for 'jslfjslfdjlskfj'
>>> help('jsflksjflkjsl') # 3.5
No Python documentation found for 'jsflksjflkjsl'.
Use help() to get the interactive help utility.
Use help(str) for help on the str class. but the latter omits decription of what 'topic' will give special output. By experiment, keywords (help('if')), builtins, and unimported modules (help('itertools')) works. Yes, 3.4 can be patched. |
No 3.4 can't be patched, this is not a security issue. A patch to make the behvior what we want should be generated against either 3.5 or 3.6, and the committer will deal with any issues arising from 3.5 vs 3.6 issues. |
Hi, I'm working on fixing this issue. |
Recapping the situations that need test cases before this can be merged:
In the latter 3 cases, the default site._Helper docs currently shown are not particularly helpful. It does make me wonder whether it might be worth defining a __help__ magic method that completely overrides what help(obj) displays. It would limit the fix to 3.7+, but it would make it possible to do this cleanly just by defining __help__ on site._Helper. |
After reviewing Sanyam's PR at #172 I ended up rejecting it as an approach to resolving this issue. The core problem with the approach is that accessing
That means importing it into a general purpose module like pydoc would couple pydoc specifically to the way CPython works, which is something we try to avoid doing. By contrast, a richer |
This should be very complex protocol if take to account that help() outputs formatted and highlighted text and pydoc can output to html format, and alternative Python shells can provide alternative help(). |
Aye, it's definitely a tricky problem. While I didn't take them into account in my review, I now realise those issues also impacted the attempted workaround - I'd be surprised if it worked as intended in those other contexts (even the "pydoc -b" rendered HTML view). As far as how to deal with the rendering complexity in a protocol, one possible way to go would be to say that rather than returning a fully rendered string, __help__() methods should return either a Python function object or a type() instance (that doesn't define __help__()), and then pydoc would render the help based on that. Regardless of the exact approach, it would be a task requiring a PEP to resolve, since rendered documentation appears in so many different contexts. |
Belatedly removing the "easy" tag, since that turned out to be thoroughly incorrect... |
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: