[Python-ideas] TypeHinting: From variable name to type

Steven D'Aprano steve at pearwood.info
Fri Oct 19 06:15:49 EDT 2018

On Fri, Oct 19, 2018 at 09:18:02AM +0200, Thomas Güttler wrote:

> Imaging you are developing in the django context.
> Everytime you use a variable named "request" or "response" your human brains
> knows that this is a subclass of  django.http.HttpRequest and 
> django.http.HttpResponse.

Not *my* human brain.

I've seen far too many variables called (let's say) "mylist" which 
actually hold a dict or a tuple (or in one memorable case, a string!) to 
unconditionally believe the name.

But I'll accept that given the context, there's a very strong likelihood 
that a variable called "request" might be a HttpRequest object, and one 
called "response" might be a HttpResponse object.

> How to give the IDE this knowledge?
> One solution is the do typehinting everywhere the veriable gets used.

You shouldn't need to. Your IDE or type-checker should be able to do 
type-inference and infer the type. You only need to add a hint if it 
cannot infer the type.

If your IDE doesn't do type inference, get a better IDE *wink*

> But why does the human brain not need this?
> Because it is intelligent?


> I would not call this intelligence. There is a simple
> dictionary in the brain of the developer, which maps:
> variable-name --> Type

Is that a fact? How do you know?

How does the information in this dict get filled in?

I think it is FAR more likely that it is intelligence: the human 
programmer understands the *meaning of the code* and would equally 
recognise that 


are all HttpResponse objects too, from the context in which they appear. 
We do that because we know the meaning of the words, and start from the 
default assumption that the coder isn't lying to us by using a name like 
"mylist" to represent a floating point number or "page_size" to 
represent the name of a file.

In other words, we *read* and *understand* the code, not just 
mechanically map names to types. That's why we have no problem with 
dynamically typed languages like Python were the one name can refer to 
objects of many different types.

When the context is different, we interpret the name differently:

    response = input("Continue? Y/n ")

    response = chatbot.lookup(question)

    response = mapping[challenge]

would all be interpreted differently, even if the module used Django. I 
doubt any reasonable programmer would imagine that they were 
HttpResponse objects.

> And this mapping dict exists once per library.

Or more likely, doesn't exist at all.

> If you are developing in the requests http lib, then
> there is a different mapping. Then "response" means
> type requests.Response.

What if you are using *both* django and requests in the same module? You 
could have both of these:

    response = something_returning_requests_Response()

    response = something_returning_django_HttpResponse()

in the one module.


More information about the Python-ideas mailing list