Use exact signatures for GObject introspection bindings

[oreiche]

Type of Changes

	Type
✓	✨ New feature

Description

With the recent change to use inspect.signature() (#2930), instead of generating signatures for all functions and methods with "wildcards" (*args, **kwargs), the exact signature could be provided for better linting.

Given the following example.py

"""Simple Example from https://python-gtk-3-tutorial.readthedocs.io/en/latest/introduction.html"""

import gi

gi.require_version("Gtk", "3.0")
from gi.repository import Gtk  # pylint: disable=wrong-import-position

win = Gtk.Window()
win.connect("destroy", Gtk.main_quit)
win.set_default_size(200)  # BUG: deliberately missing second argument
win.show_all()
Gtk.main()

... the missing second argument to set_default_size could be reported with a meaningful error message when using exact signatures:

$ pylint example.py 
************* Module example
example.py:10:0: E1120: No value for argument 'height' in method call (no-value-for-parameter)

------------------------------------------------------------------
Your code has been rated at 3.75/10 (previous run: 3.75/10, +0.00)

Risks

While this feature would substantially improve linting analysis, it would come at a noticeably higher computational cost during module loading time to generate the signatures.

Linting time for the example.py above

• 5.63 sec
• 8.87 sec (+58%)

Linting time for Apport's tests/system/test_ui_gtk.py

• 8.71 sec
• 11.45 sec (+31%)

Refs #2930

[codecov]

Codecov Report

❌ Patch coverage is 3.84615% with 25 lines in your changes missing coverage. Please review.
✅ Project coverage is 93.23%. Comparing base (3b4b7d4) to head (b8940a6).
⚠️ Report is 6 commits behind head on main.

Files with missing lines	Patch %	Lines
astroid/brain/brain_gi.py	3.84%	25 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3046      +/-   ##
==========================================
- Coverage   93.42%   93.23%   -0.19%     
==========================================
  Files          92       92              
  Lines       11315    11339      +24     
==========================================
+ Hits        10571    10572       +1     
- Misses        744      767      +23     

Flag	Coverage Δ
linux	93.10% <3.84%> (-0.19%)	⬇️
pypy	93.23% <3.84%> (-0.19%)	⬇️
windows	93.20% <3.84%> (-0.19%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
astroid/brain/brain_gi.py	19.55% <3.84%> (-2.39%)	⬇️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Pierre-Sassoulas]

Thank you for working on astroid. I didn't check the changes in detail, but the performance impact is worrying. Generally a brain is "dumb" using hard coded and very simple code is fine. Can't we do that for lower cost here ?

[oreiche]

Thank you for taking the time to have a brief look at this. I share your concern; that's why I reported the numbers. However, we probably can't speed this up much further.

Please keep in mind that the numbers I've reported (additional ~3 seconds) were measured for an end-to-end run with pylint. The additional time spent is only partly caused by the brain's signature extraction, but also by the extended checks that pylint is able to do now.

Maybe some more data for you to have the full picture:

For Gtk (example.py), the time spent for generating all signatures goes up from 0.013 to 1.355 seconds. The remaining extra ~1.6 seconds are not spent in the brain. Furthermore, almost all of the additional time in the brain is caused by the inspect.signature() call, which is run for all 49807 functions and 48942 methods in Gtk. The sheer amount of calls is part of the issue, we probably can't avoid.

For GLib, a significantly smaller library (1713 functions and 2505 methods), the time spent in the brain for generating all signatures "only" goes up from 0.001 to 0.087 seconds.

Anyway, this PR is merely a suggestion from an idea I had since my fix for the pyobject method classification. Feel free to close it if you think this enhancement is not worth the additional cost. 😄