Consider deferring module top level in type checker #6356
Comments
|
See #6312 for an example when the error happens. |
I think it's import to distinguish the ones that would fail at runtime from the ones that would not. I think there are a lot of common cases that do not fail at runtime that are worth supporting. |
Fixes #6297 This adds support for real typeshed stubs that define dummy aliases like `typing.List`, `typing.Dict`, etc. This also fixes couple related issues, so that builtin SCC is almost clean (the two remaining errors are #6295 and #6357). Most notably, this PR introduces some re-ordering of targets in builtin SCC, removing this reordering requires some non-trivial work (namely #6356, #6355, and deferring targets from `named_type()`).
|
With some more experience, it looks like this can cause troubles. More generally, the deferral in type checker is different from both semantic analyzer and the daemon: the first two defer either module top level or top-level function and defer until fixed point (our large cut-off), while type checker never defers module top levels, and defers innermost functions, and have hard-coded small number of deferrals. |
|
(Raising priority to high since this appeared again.) |
with some refactor to make sure oauth2_scheme can be passed to depends, and to make mypy happy: python/mypy#6356
We currently never defer module top levels in type checker. This can cause some
Cannot determine type of xerrors in import cycles. They are real in some sense, because such code would almost certainly fail at runtime. However, this might sometimes be useful in stubs (as practice shows, this is however not important and shows up only in highly entangled import cycles, such as e.g. builtins SCC).The text was updated successfully, but these errors were encountered: