Prefer `.pyi` stubs

[jacobtylerwalls]

Type of Changes

	Type
✓	:sparkles: New feature

Description

Closes pylint-dev/pylint#9185

[jacobtylerwalls]

but I don't have the time to test that hypothesis right now.

Neither do I. It's not straightfoward. A soft launch of this without numpy seems wise. Pushed an ugly workaround.

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 92.78%. Comparing base (4a8827d) to head (758f4d8). Report is 4 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2375      +/-   ##
==========================================
+ Coverage   92.76%   92.78%   +0.01%     
==========================================
  Files          94       94              
  Lines       11090    11098       +8     
==========================================
+ Hits        10288    10297       +9     
+ Misses        802      801       -1     

Flag	Coverage Δ
linux	92.59% <85.71%> (+0.01%)	:arrow_up:
pypy	92.78% <100.00%> (+0.01%)	:arrow_up:
windows	92.68% <100.00%> (+0.01%)	:arrow_up:

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

Files	Coverage Δ
astroid/interpreter/_import/spec.py	97.47% <100.00%> (+0.07%)	:arrow_up:
astroid/modutils.py	88.15% <100.00%> (+0.04%)	:arrow_up:

... and 4 files with indirect coverage changes

[Pierre-Sassoulas]

Yeah it would work 😄 But if we're right and our tests are actually outdated (high possibility seeing they are very old and numpy is under heavy development), we're going to prevent numpy from having this new feature. Tbf I did not intend to check everything just check one test to confirm or not. Trying to find the motivation to download numpy and start reading atm. (Also we have a ton of brain for numpy, I those brains could become a pylint-numpy plugin so we don't have to block astroid for lib specific behavior) .

[jacobtylerwalls]

@Pierre-Sassoulas do you think we can get this into astroid 3.2 as is?

[jacobtylerwalls]

pylint primer result

[Pierre-Sassoulas]

Yeah we can release as is and not make astroid worse than it is at the moment. I keep this on my mind but handling the flow of issues and then, at the end of a big pile of issues, finding the motivation to open numpy's code and compare it to the astroid's numpy brains and unit tests ..is proving difficult. Might need to create an issue for the numpy / pyi / outdated tests checks in the end.

[Pierre-Sassoulas]

Or a pylint numpy plugin.

[jacobtylerwalls]

I hear you. Plus, what if we get negative user-feedback on this first push -- don't want to sink time into a big numpy yak shave that turns out to be wrong-track!

[mbyrnepr2]

Or a pylint numpy plugin.

Should that be standalone and a dependency for pylint-ml?

[Pierre-Sassoulas]

Yeah that sounds good but we'd need a proof of concept first. Probably on a smaller lib with less users affected if we drop the brain from astroid/pylint by default to test the water.