[Python-ideas] TypeHinting: From variable name to type
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
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
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
> 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