Repository navigation
Consider deferring module top level in type checker #6356
Description
We currently never defer module top levels in type checker. This can cause some Cannot determine type of x errors 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).
Activity
ilevkivskyi commentedon Feb 7, 2019
See #6312 for an example when the error happens.
russelldavis commentedon Feb 7, 2019
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.
New semantic analyzer: Support builtin typing aliases (#6358)
ilevkivskyi commentedon Sep 3, 2019
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.
ilevkivskyi commentedon Sep 24, 2019
(Raising priority to high since this appeared again.)
Add OAuth2AuthorizationCodeBearer