Function is not accessed (although it IS accessed)

[ibobak]

Type: Bug

Please, look at the screenshot below: the functions are accessed.
If we do "go to definition", it will work.

The project on which this is reproducible is available here
https://github.com/ibobak/spark_framework

Extension version: 2024.5.1
VS Code version: Code 1.89.0 (b58957e67ee1e712cebf466b995adf4c5307b2bd, 2024-05-01T02:08:25.066Z)
OS version: Linux x64 6.4.6-060406-generic
Modes:
Remote OS version: Linux x64 6.5.0-27-generic

System Info

Item	Value
CPUs	AMD Ryzen 7 3700X 8-Core Processor (16 x 4086)
GPU Status	2d_canvas: enabled canvas_oop_rasterization: disabled_off direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_graphite: disabled_off video_decode: enabled video_encode: disabled_software vulkan: disabled_off webgl: enabled webgl2: enabled webgpu: disabled_off
Load (avg)	0, 0, 0
Memory (System)	46.95GB (27.10GB free)
Process Argv	--crash-reporter-id d91c5c25-2c49-4af3-80cb-302636dde5af
Screen Reader	no
VM	0%
DESKTOP_SESSION	ubuntu
XDG_CURRENT_DESKTOP	Unity
XDG_SESSION_DESKTOP	ubuntu
XDG_SESSION_TYPE	x11

Item	Value
Remote	SSH: macpro2
OS	Linux x64 6.5.0-27-generic
CPUs	Intel(R) Xeon(R) W-3275M CPU @ 2.50GHz (28 x 2493)
Memory (System)	125.78GB (64.68GB free)
VM	100%

A/B Experiments

vsliv368cf:30146710
vspor879:30202332
vspor708:30202333
vspor363:30204092
tftest:31042121
vswsl492cf:30256860
vscoreces:30445986
vscod805:30301674
binariesv615:30325510
vsaa593cf:30376535
py29gd2263:31024239
c4g48928:30535728
azure-dev_surveyone:30548225
962ge761:30959799
pythongtdpath:30769146
welcomedialog:30910333
pythonidxpt:30866567
pythonnoceb:30805159
asynctok:30898717
pythontestfixt:30902429
pythonregdiag2:30936856
pyreplss1:30897532
pythonmypyd1:30879173
pythoncet0:30885854
h48ei257:31000450
pythontbext0:30879054
accentitlementsc:30995553
dsvsc016:30899300
dsvsc017:30899301
dsvsc018:30899302
cppperfnew:31000557
dsvsc020:30976470
pythonait:31006305
dsvsc021:30996838
9c06g630:31013171
pythoncenvptcf:31043158
dwnewjupytercf:31039676

[erictraut]

Pyright (the type checker that underlies pylance) is working as intended here. These symbols are not referenced anywhere in the file. You appear to have enabled the reportUnusedImport diagnostic error, which is off by default. When you enable this check, pyright will report an error if your file includes an imported symbol that is not used anywhere within the module and is not re-exported to other modules. In your case, I suspect you intend for these symbols to be re-exported to other modules. By default, symbols imported into a module are assumed to be private (internal) to that module. If you intend to re-export them to other modules, you need to use one of the techniques documented here. You can either include them in an __all__ or use a redundant form of import (for example, from x import y as y). This convention was established in PEP 484 for stub files, but the typing community has since adopted it for ".py" files as well.

If you don't want pyright to generate an error for unreferenced imports, you can choose to disable the reportUnusedImport in your project or on a per-file basis using a # pyright: reportUnusedImport=false at the top of the file.

[ibobak]

@erictraut, thank you very much for your answer. Yes, you are right: they are not referenced in the file.
However, this file __init__.py means that this is a package, which later will be used by other modules. In my case, I am writing

from spark_framework import *

from other parts of the code, and due to this import of functions that is surrounded by red rectangle on my screenshot, they are imported fine.

However, it looks like Pylance doesn't recognize it to be in the __init__.py and doesn't get the real intention.

[debonte]

However, this file __init__.py means that this is a package, which later will be used by other modules.

As Eric mentioned above, if you want to re-export these symbols from this module (and you want a static type checker to understand that that is your intention) you'll either need to include them in an __all__ or use a redundant import form (from x import y as y).

I've copied that part of his response here:

By default, symbols imported into a module are assumed to be private (internal) to that module. If you intend to re-export them to other modules, you need to use one of the techniques documented here. You can either include them in an __all__ or use a redundant form of import (for example, from x import y as y). This convention was established in PEP 484 for stub files, but the typing community has since adopted it for ".py" files as well.