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