Pyright doesn't respect submodules of submodules that are already explicitly imported

[LeeeeT]

I have the following project structure:

root
├── a
│   ├── b
│   │   ├── c
│   │   │   ├── __init__.py
│   │   ├── __init__.py
│   ├── __init__.py
└── main.py

I want to access a.b.c module in main via b.c (not a.b.c nor c). So I wrote this code in main:

import a.b.c
from a import b

print(b.c)

This works at runtime, but causes an error in pyright ("c" is not a known member of module). And I don't understand why. c is present in b not because of a side effect, but because of my explicit import. Is this an intended behavior? And if it is, how should I fix my code to get rid of the error and still being able to access a.b.c module by writing b.c in the main file?

pyright 1.1.261
python 3.10

[erictraut]

Yes, this is intended behavior. The code above relies on temporal side effects of the Python import loader. In particular, it relies on the fact that when you import a.b.c, that submodule b happens to have an attribute c cached that represents the submodule c. It's inadvisable to rely on such side effects because small changes in the code can change assumption and break things at runtime. In the general case, static type checkers cannot model such side effects because they depend on temporal order of global execution. Pyright therefore doesn't attempt to model such side effects even in special cases and treats all reliance of such side effects as errors.

In your example above, if you want to access c, you should explicitly import it, for example, through the use of the statement from a.b import c.