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

[Anders Hovmöller]

> On 19 Oct 2018, at 12:15, Steven D'Aprano <steve at pearwood.info> wrote:
> 
> 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.

This is an even stronger argument for the proposal I think. If IDEs and static analysis tools looked at stuff like this and assumed a type _and then found that this assumption is violated_, it would be a huge win!

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


Which IDE would this be? PyCharm doesn't do this in the general case. Not even close in the code base I work on.


>> And this mapping dict exists once per library.
> 
> Or more likely, doesn't exist at all.

You seem to argue here, and generally, that the normal case for code bases is that you have no consistent naming. This seems strange to me. Can I ask what type of code and how big code bases you work on? To me it seems we have radically different perspectives, and we'll continue talking past each other if we don't explain those perspectives to each other.

I'll go first: I work on a code base that:
- is ~240k dry lines 
- is ~15 years old
- it a web app with just one production install
- has very good consistent naming, for example:
    - the "request" example above exists over 6000 times in the code base and all of them are HttpRequestBase-derived (or in a few cases a mock that pretends to be that). 
    - the word "party" exists over 11 thousand times, all of them are an instance of the Party django model

Being able to tell PyCharm to assume the type of these and flag obvious violations would be great.


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

Then you'd use the normal typing annotations to override the default.


/ Anders