-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Plugin api named_type() is ambiguous and inconsistent and broken #6578
Comments
This is related to #4157. We are going to fix this after we are done with the main part of the refactoring (i.e. soon). |
This is a separate problem I think. @Michael0x2a do we already have an issue for this? |
Related to #6578 This PR replaces lookup_qualified with lookup_fully_qualified for SemanticAnalyzer.named_type. Now it's consistant with the implementation of checker.named_type. This change also allows calling named_type without dunders.
FYI: sqlmypy is hit by this api change: dropbox/sqlalchemy-stubs#232 |
) Related to python#6578 This PR replaces lookup_qualified with lookup_fully_qualified for SemanticAnalyzer.named_type. Now it's consistant with the implementation of checker.named_type. This change also allows calling named_type without dunders.
Related to python#6578. builtin_type could be totally replaced with named_type after python#11332. Also renames other builtin_type for consistency since all of them are actually calling named_type.
The plugin API defines two different interfaces (TypeAnalyzerPluginInterface and SemanticAnalyzerPluginInterface) that each define a method named_type(). These look almost identical, but looks are deceptive.
First, the specified signatures differ subtly:
Second, the implementations differ:
Third, the type checker's named_type() implementation doesn't actually take a list of type arguments at all -- it's a method with only one argument, the name to look up. It always fills in all type parameters with Any. (It looks like the method we want here is named_generic_type().)
Fourth, apparently mypy's own type checking doesn't catch the discrepancy between the implemented spec (only a name) and the interface spec (name + args).
The text was updated successfully, but these errors were encountered: