Plugin api named_type() is ambiguous and inconsistent and broken

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:

• The second argument to SemanticAnalyzerPluginInterface.named_type() is optional, while for TypeAnalyzerPluginInterface.named_type() is is mandatory.
• Also the first argument name differs (qualified_name vs. plain name).

Second, the implementations differ:

• The semantic analyzer (in semanal.py) starts the lookup in the local namespace, then globals, then builtins.
• The type checker (in checker.py) has two different strategies: if there's no dot in the name, it starts in globals, then builtins; but if there's a dot, it starts in the table of modules (i.e. the current scope doesn't enter into it).

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).

Commencez par comparer TypeAnalyzerPluginInterface.named_type() et SemanticAnalyzerPluginInterface.named_type() avec les implémentations dans semanal.py et checker.py. Examinez named_generic_type() et la configuration de la vérification des types afin de comprendre pourquoi la divergence de signature n’est pas détectée. La tâche est terminée lorsque les interfaces et les implémentations des plugins disposent d’une API cohérente et convenue, et que la divergence est couverte par la vérification des types ou par des tests.