[Python-ideas] TypeHinting: From variable name to type
steve at pearwood.info
Sun Oct 21 20:13:32 EDT 2018
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:
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
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?
> >>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
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
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
> 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 :-)
More information about the Python-ideas