-
Hi, I have a problem with import cycles, i tried different things, but pyright does always complain I uploaded a test repo with a simple example https://github.com/lovetox/testproject Result:
i think pyright does not really check for runtime import cycles. because there are none. It seems to discover import cycles while type checking. But are those an issue? As i see it its impossible to resolve these import cycles that only exist because of type hints and which TYPE_CHECKING should solve. This is on pyright 1.1.214 |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
Runtime cycle detection is not generally possible to detect statically. It depends on temporal ordering of imports and symbol accesses. Pyright's cycle detection was designed to detect architectural layering violations. In well-designed programs, modules should generally be strictly layered. If module A imports from module B, there should be no use of types defined in module A within module B. If there are, the code should be refactored to move the common types into the "lower" module or into some common module that is "lower" than both A and B. This form of cycle detection may report some cases that do not result in runtime cycle violations. |
Beta Was this translation helpful? Give feedback.
Runtime cycle detection is not generally possible to detect statically. It depends on temporal ordering of imports and symbol accesses.
Pyright's cycle detection was designed to detect architectural layering violations. In well-designed programs, modules should generally be strictly layered. If module A imports from module B, there should be no use of types defined in module A within module B. If there are, the code should be refactored to move the common types into the "lower" module or into some common module that is "lower" than both A and B.
This form of cycle detection may report some cases that do not result in runtime cycle violations.