Intellisense does work with GTK+ 3 (GObject Introspection)

[jrsrjrsr]

Environment data

• Language Server version: v2020.11.2
• OS and version: Ubuntu 20.04 (WSL2) on Win 10, 19041.630
• Python version (& distribution if applicable, e.g. Anaconda): Python 3.8.5

Expected behaviour

Autocomplete should show member functions and variables for GTK+ 3 library (import gi)

Actual behaviour

Autocomplete does not work for import gi

Logs

Nothing of relevance appeared to be in the logs for the language server. Things like: "setFileOpened, getDiagnosticsForRange, parsing file, binding, file, getSemanticTokens", but nothing odd.

Code Snippet / Additional information

• Install GTK graphical user interface library -- gir bindings (gir1.2-gtk-3.0)
• Install Python 3 bindings for gobject-introspection libraries (python3-gi)
• Try to autocomplete Gtk.

import gi
gi.require_version('Gtk', '3.0')
from gi.repository import Gtk
win = Gtk.

Key issue: This works as expected if I change the language server to jedi, but does not work with pylance. Autocomplete also works fine in the Ubuntu command line interpreter (python3).

Related discussion that I found (but had trouble interpreting) on other github projects:

• jedi GTK+ 3 (GObject introspection) microsoft/pylance-release#531
• vscode-python Autocomplete doesn't work for Gtk+ 3 microsoft/pylance-release#582

[judej]

@jrsrjrsr, thanks for the report. GTK is a compiled module so we need to create stubs for it. Until then, there will not be completions. I will add this the list of compiled modules that need stubs.
Thanks

[sickpancake]

Hello - any update on this issue?

I am using VSCode + Pylance for Python/GTK coding. Unable to autocomplete is a bit inconvenience. Would appreicate if there is a progress. Thanks!

[erictraut]

This library doesn't contain any type information currently, and it's largely written in compiled code, so type information cannot be inferred from Python sources. Someone who is familiar with the library will need to create type stubs for the library. Ideally, the library authors would include these stubs with the library so consumers of the library don't need to locate and install the stubs separately. This is the approach most library authors are taking. If this is a library that you depend upon, please consider filing a feature request with the library authors. If you're really ambitious, consider contributing type stubs to the pygtk project.

[szblajos]

How about pygobject-stubs project on github? It is located here.
Although it is currently in a very early state (0.0.8), but seems to be a promising one

[fcole90]

As a temporary solution, you can use fakegir to produce stubs: https://github.com/strycore/fakegir

[Avasam]

How about pygobject-stubs project on github? It is located here. Although it is currently in a very early state (0.0.8), but seems to be a promising one

And as of today it's still being actively maintained. I'd recommend using existing stubs and/or contributing to them. @jrsrjrsr

[Avasam]

A bit of a bump, but I do think users are better off using existing and actively maintained community stubs (https://github.com/pygobject/pygobject-stubs) rather than adding here.