pylance and pylint are unable to resolve package content

[mariuswallraff]

Describe the bug

VS Code fails to resolve functions imported from simplification (e.g., via from simplification.cutil import simplify_coords_vw_idx), and pylint fails on GitLab's CI/CD with E0611: No name 'simplify_coords_vw_idx' in module 'simplification.cutil' (no-name-in-module) despite all tests passing (i.e., the import works at runtime).

System (please complete the following information)

• OS: linux (GitLab CI/CD)
• Architecture: x86_64
• simplification 0.7.10, python 3.12, pylint 2.17.7

Additional context

I suppose a solution might be to add an __init__.py to the src directory. For Python 3.3+, that's not strictly required due to namespace packages existing, but it seems pylint cannot handle that perfectly yet, nor can VS Code's Pylance.

https://github.com/pylint-dev/pylint/issues/4057

[urschrei]

So this isn't a bug in the package? I'm happy to look at a PR if there's some additional justification for modifying the structure; is there usually an __init__.py in src? Can we confirm that this fixes the issue.

[mariuswallraff]

Thanks for you response!

I had another look at it, forked your code and tried some things.

Reloading (and updating my VS Code Jupyter extensions, but that should be unrelated) at least fixed the explicit "cannot resolve" message by Pylance, but it still cannot tell the number of input arguments; see this picture for comparison to a random numpy function:

Related to this, neither simplifcation nor simplifcation.cutil have any mouse-over pop-ups, unlike other modules where it says (module) MODULENAME, plus a module docstring if it exists.

The __init__.py I suggested didn't help, neither for Pylance nor for pylint:

from simplification.cutil import simplify_coords_vw_idx

from numpy.ma import mask_cols

a = [
    [0.0, 0.0],
    [0.1, 0.0],
    [0.25, 0.5],
    [0.4, 1.0],
    [0.6, 1.0],
    [0.7, 1.0],
    [0.8, 0.3],
    [0.9, 0.1],
    [1.0, 0.0],
]

out = simplify_coords_vw_idx(a, 0.1)

print(out)

To be fair, this isn't a big deal, the module works well even with these minor "problems".

I'll keep my fork around and hope I'll have time to revisit this at some point, especially if I learn anything new regarding possible fixes.

[cheginit]

I can open a PR to address this issue. Explicitly adding public APIs to __init__.py (and __all__) is one of those best practices for Python packaging. You can find an example in one of my packages here.