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

[Thomas Güttler Lists]

Am 19.10.18 um 12:15 schrieb Steven D'Aprano:
> 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 know that I know nothing, or at least not much. My laptop does compute 
much faster than I do


> 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.


Great, we agree here.

>
>> 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*


I use the free community version of pyCharm, and it often does not know

which type a variable has. A simple name2type mapping would improve

the situation a lot.


>
>> 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?


as I already said before a docstring in the __init__.py file would

be a pragmatic solution.


> 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


I try to use the same variable name again and again. I guess in my

code base in 95% an instance of HttpRequest is stored in a variable 
called "request".

You say:  the human programmer understands the *meaning of the code*

Great if that is the case for you. I often look at the code and don't 
get it at all.

I wrote the lines two years ago, and today I don't understand why they 
exist.

This does not happen daily, but at least once a month.


> 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.

relax. I mean this like I said. Please relax.

Imagine you have this: reposense = obj.get_response()

First: if the variable is the return value of a method, and the method

has type-annotated the return value, then this type information gets used.

End of type detect.

If the type information can't be found from the method, then use the 
name2type

mapping which I suggest in this mail.





>
>> 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.
>

Do you really care for this edge-case? I don't.

The way to get the type info is the same: Check the method,

if it has it use this. Do not use name2type mapping. End of type detection.

Then check the current file or the above __init__.py of the code. Take

name2type mapping from there.


Regards,

   Thomas Güttler


-- 
Thomas Guettler http://www.thomas-guettler.de/
I am looking for feedback: https://github.com/guettli/programming-guidelines