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

[Steven D'Aprano]

On Sat, Oct 20, 2018 at 07:53:18PM +0200, Thomas Güttler Lists wrote:
> 
> Am 19.10.18 um 12:15 schrieb Steven D'Aprano:

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

If the free community version of PyCharm doesn't support type-inference, 
what makes you think it would support this "name2type" mapping?

I don't use PyCharm, and I don't know if this feature applies to the 
free version, but according to their blog, PyCharm not only supports 
type-inference but also uses dynamic runtime information to enhance 
static type checking:

https://blog.jetbrains.com/pycharm/2013/02/dynamic-runtime-type-inference-in-pycharm-2-7/

If you find yourself needing to annotate lots of variables, I suspect 
that you're fighting the IDE rather than using it correctly. Without 
seeing your code, and knowing a lot more about PyCharm, I cannot say 
further.

But the critical point here is that we should not add a language feature 
to make up for the limitations of a single IDE. If the free version of 
PyCharm is underpowered, perhaps you ought to try the paid version, or 
another IDE, or submit a feature request to PyCharm, *before* turning to 
the Python language.



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


You misunderstand me. You claim that there is a dictionary in the brain 
of the developer, right now. How does that dictionary *in the brain* 
get there, if it isn't through the use of human intelligence?

I believe you are too focused on a single specific implementation:

    "use a dict to map variable name to type -- I know how to 
    implement this, therefore that is what the brain must do"

whereas I think that the reality is more complex: what you see as a 
mapping, I expect is just a special case of more general, and far more 
powerful, general reasoning intelligence.

We can infer types from variable names, because we know what the name 
means, not because "there is a simple dictionary in the brain of the 
developer" mapping name to type.

    exchange_rate # probably a float
    num_rows      # number of rows, therefore an int
    name          # a string
    phone_number  # not a float! should be a string
    response      # a response from something (depends on context)

If we read Greek, we'd probably even recognise that a variable called 
"όνομα" was likely to be a string.


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


Please don't patronise me. Just because I disagree with your suggestion 
doesn't mean I am freaking out and need to be told to relax.

We should not implement new features after ONLY considering when the 
feature would be useful. We should also consider when the feature is not 
needed, and when it would be actively harmful, and weigh it on the 
balance.

Your suggestion is useful when:

- you use the same variable name over and over again;

- always (or almost always) to mean the same type;

- and type inference won't work;

- and you don't want to annotate the variable each time;

- and the IDE supports this new feature;

- and there is little or no chance that you might want to 
  use the same name for a different type in the same module.


It is not useful, maybe even harmful, if any of those conditions are not 
met. I'm especially concerned about the last one: type-checking false 
alarms due to a clash between the name2type mapping and the programmer's 
intention.

But on the other hand, if this is a convention purely implemented by 
IDEs, then I don't give a damn about this one bit. (Except to say, take 
the discussion to the "code-quality" mailing list, not here.) It doesn't 
sound like something that needs language support.


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

Of course I do. It isn't an edge-case, it is representative of the vast 
majority of variable names:

- "A single variable name is always the same type" is the edge-case.

- "A single variable name can represent different types in different 
  contexts" is the general case in dynamically-typed languages like Python.

So we should care about the case where variables are reused in different 
contexts.


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

So why doesn't that already work for you? Why do you need name2type 
mapping *at all* if this problem is so easy to solve?

The bottom line here is that I don't think this needs language support, 
I would be against adding language support, but if IDEs want to support 
this, so long as they offer a switch to turn it off I don't care what 
they do :-)


-- 
Steve