nipy
pylance warning reportPrivateImportUsage
import nibabel data_path = 'path/to/your/data.nii' img = nibabel.load(data_path)
It raises up warning around the load. Any suggestions? Thanks
Alright. Do you have a reproduction, including pylance invocation? I've never used the tool, so any help in getting started would be appreciated.
in the vscode, when I use the script above, it shows up the warming. The problem is similar when I used obj.get_data(), nib.Nifti1Image, obj.affine, and nib.save
import nibabel
data_path = 'path/to/your/data.nii'
img = nibabel.load(data_path)
I would ask the pylance developers how to reproduce this more directly. vscode is too complex to be a useful reproduction.
I think adding an __all__ to __init__.py would resolve this warning (by explicitly making the intended symbols public), but I don't know if there's a design reason to not set __all__ here?
The design reason is that nibabel is old and comes from the consenting adults phase of Python, and people will depend on any unintentional behavior of import nibabel as nib, such as things that are not explicitly imported still being in the namespace. Does __all__ preserve that? I've never tried to retrofit it into an old codebase that people are depending on to not change.
Does all preserve that?
If __all__ literally includes all the public symbols in __init__.py, the resulting namespace from import nibabel as nib should be the same.
And I should clarify the __all__ should fix the warnings for nib.load and nib.save but not for the methods and attributes ― those would need typing stubs that specify all the attributes that could arise from things like dynamic type detection, which could be quite a lift.
Given that this is just a way to satisfy a type checker, I would suggest that a PR add an __init__.pyi. That should make pylance happy without any risk of failing to export something (the namespace is pretty large). If it's in a stub, it may not need __all__ to be added, so it might be a pretty easy copy-paste job.
For improving the type hints on nibabel objects: https://github.com/nipy/nibabel/discussions/1220
I think an __init__.pyi is exactly the way to go (and an __all__ in the *.pyi should satisfy the linter). I'll put in a PR shortly.