Try to resolve documentation with pydoc when docstring is not found

[zdzislaw-s]

When trying to resolve documentation for the cursor word fallback to pydoc in case when getting a docstring fails.

Before

After

[davidhalter]

Why would you use keywordprg, which defaults to man for that? Also Jedi already falls back to pydoc for documentation.

So I doubt that this is a good solution.

[zdzislaw-s]

Why would you use keywordprg, which defaults to man for that?

In fact, for the .py files, the ftplugin shipped with vim sets up the keywordprg to pydoc.

Also Jedi already falls back to pydoc for documentation.

This was not my experience as evidenced in the screeshots.

[davidhalter]

If that's the case we have to work on Jedi's abilities then. As I said before in other places, I won't add pydoc to jedi-vim, because Jedi already uses it under the hood. If there are bugs like we might have here, we should look at that.

BTW in my experience documentation on list literals works. You probably have to define more clearly what you are doing.

In fact, for the .py files, the ftplugin shipped with vim sets up the keywordprg to pydoc.

This is not my experience, but I might be using a different VIM than you.

[zdzislaw-s]

I showed my use cases in the screenshots but admit it may not be immediately obvious what is happening there.

In the first Before screenshot, my cursor is positioned on the list word and want to see what kind of documentation I can get when I hit K. Without the patch, I'm getting: |No Docstring for <Name full_name='test.list', description='list = []'>|

with the patch, I'm getting text that is created by pydoc list. You may argue the you get some documentation when your code looks more like:

alist = list()

but in such case that documentation is not much of use to me:

Docstring for class builtins.list
=================================
list()
list(iterable: Iterable[_T])

Built-in mutable sequence.

If no argument is given, the constructor creates a new empty list.
The argument must be an iterable if specified.

I guess, the question here is how can I find out what the API of the built-in list is.

In the second Before screenshot, my current cursor word is graphene and again, when I hit K, I'm getting the No Docstring... message, whereas with the patch, I can read the help on the graphene package.

I might be using a different VIM than you

That's probably more than might... but have a loot at this - the pydoc is there: https://github.com/vim/vim/blob/ec6e63079dde24a1d74b4103775e74d00f9215ec/runtime/ftplugin/python.vim#L122

[davidhalter]

OK, at least I understand you feature request somewhat better now. I disagree with the list = example returning the list docstring. graphene on the other hand does not seem to have a docstring: https://github.com/graphql-python/graphene/blob/0a54094f59e1b1bca83e4574dbb35587536bbce6/graphene/__init__.py. If pydoc executes graphene in that case and somehow gets information out of it: That's exactly not what I want to do. Mostly for security/safety reasons. It's a bad idea.

I'm closing, because as I said I disagree with the list example and the graphene one is simply a missing docstring. For all other cases, (like the list one) we would probably have to discuss how to approach this from Jedi's point of view. Jedi could easily just do type inference there, I just think that's kind of confusing.