In October 2018 on the mailing list python-ideas some developers encouraged me, that the idea of a name2type mapping would be usefull.
Source code should be clean. Every character which is not needed for my eyes/brain to understand the code should not be on the screen.
Imagine you work on a Django project. Many methods will have the request as first argument. Every django develop knows that I mean django.http.HttpRequest.
So if my eyes and brain just need the string request to understand what this variable is, then there should be a way
for the interpreter/compiler to understand this, too.
Since interpreter/compilers are not smart, we need a way to make them understand this "name to type mapping".
The name2type mapping is defined in the docstring of a Python file.
The general syntax is "name2type:" followed by a comma sperated list of variable names. Then ":", then the type hint.
Examples:
name2type: my_int, my_number, ....: int
name2type: request*: django.http.HttpRequestIf the docstring is in a file called __init__.py, then the type hints get specified for all files below this directory (recursively).
Your code base contains a variable name "request" 100 times, and in 70 times the variable type is an instance of "django.http.HttpRequest" (detected by usual type annotations). If you want to have valid type information of all occurences of "request" in your code, then you need to find a solution for 30 usages. You could annotate the variable in your code 30 times (once per method). Or you could define a name2type mapping in the __init__.py file if your code.
Above argument makes me unsure what the best solution looks like. Do an explicit name2type mapping, or leave it up to the stats. There are conflicting guidelines. The guidelines "less is more" and "avoid redundancy" on one side, and on the other side "explicit is better than implicit".