Plugin API feature requests

I recently wrote a plugin that used get_function_hook() to intercept instantiations of a certain set of classes (recognized by name), and found a bunch of functionality missing. Here's a list.

• I needed the names of the arguments but they were not directly available. I ended up using rtype.type.names['__init__'].node.arg_names (with various type and None guards) and subtracting 1 to compensate for self, which looked very hacky. It would be nice if FunctionContext also has an arg_names argument.

• CheckerPluginInterface has no fail() method. It exists on the implementation, and the similar TypeAnalyzerPluginInterface does define it.

• I needed to look up a name in the module's global namespace; I ended up calling ctx.api.lookup_qualified() but that's not in the interface, and perhaps it's not the thing to use.

• I needed the functionality of parse_bool() but it's not there (it only exists on SemanticAnalyzerPluginInterface).

• I needed something similar to what's in mypy/plugins/common.py as _get_bool_argument() _get_argument() but had to write my own because the starting point was a FunctionContext instead of a ClassDefContext.

• (Not directly a plugin issue, but this happened.) I was also bitten by the error message The type alias{} is invalid in runtime context -- this seems a bit inconsistent because expanding the Union that the alias references makes it go away. I.e. if A = Optional[int], foo(A) gives that error, but foo(Optional[int]) doesn't.

Examinez les interfaces de plugins autour de FunctionContext, CheckerPluginInterface et SemanticAnalyzerPluginInterface, ainsi que mypy/plugins/common.py et le comportement signalé des alias de types à l’exécution. L’issue contient plusieurs demandes d’API distinctes plutôt qu’une seule modification délimitée ; sa réalisation nécessiterait de décider quelles demandes sont prises en charge et de définir leur comportement attendu.