IntelliSence issues

[KristofMerey]

1. It was an issue already in the previous Python extension: in quick info, line breaks are poorly handled. For example, now I use Google-style docstrings in a project, and the whole text appears without any line breaks in quick info. At NumPy, titles (Parameters, Returns, See Also, etc.) rendered adequately; however, the list of parameters follow each other without any breaks.

2. Quick info hides the function annotation and provides type information instead. That's a problem because the docstrings usually refer to parameter names which are lost. (E.g. first line in quick info of np.mean is this: (function) mean: Any | _AnyCallable, while first line produced by help(np.mean) is mean(a, axis=None, dtype=None, out=None, keepdims=<no value>).) Parameter info also suffer from this and cannot help the calling.

3. There is no information about functions of OpenCV, despite help works properly (and so the old Python extension could fetch quick info and parameter info as well). What is worst, that some built-in functions (for example open, len, etc.) and some standard library functions (os.remove, os.path.join, random.seed, random.randint) lack of proper quick info, meanwhile others work well (glob.glob, re.sub, subprocess.Popen).

I'm using v2020.7.1 of Pylance, 3.8.0 of Python, 1.47.0 of VSCode on Win10.

By the way, I like your new extension and hope it'll be successful.

[jakebailey]

Addressing each of these:

1. The docstring formatting code is identical to that used in the previous language server; we know this stands to be improved, see Support for different docstring formats #48.

2. Those functions in numpy are compiled code, so we aren't able to extract the docstrings (pylance cannot correctly recognize array objects in numpy module. #93), though I'd appreciate a screenshot of that Any | _AnyCallable case, as I'd have guessed we would have no type info at all for many numpy functions. Are you using a version of numpy that includes their stubs? @KristofHorvath

3. Same as before, we don't yet support compiled code: Missing docstrings for builtins #49 for builtins, No suggestions for cx_Oracle #103 is also compiled code. Any solution that involves help() is one where we need to call out to Python and actually run the libraries, which we aren't currently doing.

[KristofMerey]

Thank you for your answer.

2. It was hard to reproduce the observed behaviour since I used another version of Python in the project where I tested numpy (and I didn't recognise it).

In Python 3.8.0 with NumPy 1.18.0:

In Python 3.7.2 with NumPy 1.16.2:

NumPy was installed with pip in both cases.

3. I understand why you don't want to run the modules; however, it would be an acceptable workaround at compiled modules without stubs, wouldn't be?

[jakebailey]

Can you try again with numpy 1.19? I'm thinking that their stubs are now included, so I'm curious if this improves things.

I understand why you don't want to run the modules; however, it would be an acceptable workaround at compiled modules without stubs, wouldn't be?

We don't want to do this without some careful planning, at least not at the moment. This means calling out to python and executing the code to gain its info; it's not static and is pretty imperfect.

[KristofMerey]

With NumPy 1.19.1, the result is the same as with 1.18.0, which was already good enough for me.

[jakebailey]

I'm going to close this in favor of other issues that are more targeted toward specific things; this issue reports three issues in one.

For docstrings: #48

For OpenCV: #138

For numpy: #150