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?
Yes.
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 myresponse response2 reply answer rspns 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. -- Steve