-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[red-knot] Rethink public types of symbols in function-like scopes #15777
Comments
Just to be clear, the "should reveal" assertions in the example above are based on what we would currently reveal for a similarly-defined symbol in a module level scope, if we don't consider the Barring any attempt to analyze where the nested scope can be called from, I think the starting point has to be that all definitions are visible, regardless of control flow. (This is effectively modeling that Also, for symbols in function-like scopes, if we don't see a nested scope with a All of that is to say: we have a lot of design work to do on types for closed-over variables, and "the status quo before terminal support", as documented in the tests shown above, is not a very good guide to the desired eventual behavior. |
I've updated the issue description to not presume what behavior we'll want to implement. |
#15676 currently has the following mdtest with incorrect results:
We should determine how we want to handle the assignments in this scope.
One possibility (which mimics our current behavior for module-level scopes) would be to reveal
Literal[1, 2, 3]
for all three. (This would require changes to our terminal statement support: we currently purposefully resolve thex
use in the nested function relative to the end off
's scope, but thereturn
statements are preventing some of the bindings from being visible there.)The text was updated successfully, but these errors were encountered: