Skip to content
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

Clean-up type variable scope and binding #4814

Closed
ilevkivskyi opened this issue Mar 28, 2018 · 3 comments
Closed

Clean-up type variable scope and binding #4814

ilevkivskyi opened this issue Mar 28, 2018 · 3 comments
Labels
meta Issues tracking a broad area of work priority-1-normal refactoring Changing mypy's internals semantic-analyzer Problems that happen during semantic analysis

Comments

@ilevkivskyi
Copy link
Member

Currently the code around type variable binding in functions is a bit unclear and does some strange things like binding typer variables before function type is analyzed and depending on TypeVarQuery returning short (unqualified) names.

@ilevkivskyi ilevkivskyi added refactoring Changing mypy's internals priority-1-normal labels Mar 28, 2018
@ilevkivskyi
Copy link
Member Author

Another related comment here is that we have a bit too many "things" related to type variables (in addition to TypeVarScope mentioned above):

  • TypeVarExpr
  • TypeVarDef
  • TypeVarType
  • TypeVarId
    We can probably simplify a bit the model of how type variables work.

@ilevkivskyi
Copy link
Member Author

Probably it makes sense to clean up (or at least document) various things related to type variable scopes while we are working on the new semantic analyzer. I just discovered an inconsistency in new analyzer, it was using full type variable name where short one was expected. Without documentation, such errors are easy to make.

@ilevkivskyi ilevkivskyi added the semantic-analyzer Problems that happen during semantic analysis label Feb 24, 2019
@ilevkivskyi ilevkivskyi self-assigned this Feb 24, 2019
@ilevkivskyi ilevkivskyi removed their assignment Dec 9, 2019
hauntsaninja added a commit that referenced this issue Aug 4, 2021
In the spirit of #4814 (comment)

I'm not sure what the distinction between TypeVarDef and TypeVarType was (note that there's also TypeVarExpr, whose purpose is clear to me).
In practice, it seems it boiled down to: a) TypeVarDef has a different __repr__, that's not user facing but was used in tests, b) in two places, we used the construction of a TypeVarType from a TypeVarDef as an opportunity to change the line number.

I ran into this because:
a) I was considering whether to create a corresponding ParamSpecDef and ParamSpecType
b) I was trying to fix an issue with applytype sometimes swallowing generics, which to fix I needed TypeVarType to have access to its TypeVarDef.
I was unable to find a reason for TypeVarType to not just be the TypeVarDef and here we are.

Co-authored-by: hauntsaninja <>
@ilevkivskyi ilevkivskyi added the meta Issues tracking a broad area of work label Aug 28, 2022
@ilevkivskyi
Copy link
Member Author

FWIW I more happy now with how type variables work (e.g. we use namespaces everywhere). There still may be bugs, I think tvar_scope.py is somewhat over-complicated, but we can handle issues on one-by-one basis now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
meta Issues tracking a broad area of work priority-1-normal refactoring Changing mypy's internals semantic-analyzer Problems that happen during semantic analysis
Projects
None yet
Development

No branches or pull requests

1 participant