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

[Steven D'Aprano]

On Fri, Oct 19, 2018 at 01:14:39PM +0200, Anders Hovmöller wrote:

[I wrote this]
> > 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!

That's an argument for *static type checking*, not necessarily an 
argument for *this* specific proposal. Any method of checking types, be 
it static typing, mandatory type declarations, type inference, stub 
files, annotations, or anything else, would help in that situation.

This specific proposal assumes that when you have a single name, it 
always (or at least, nearly always) means the same type, across an 
entire package. Therefore it is safe to map the name *alone* to the 
type, rather than annotate the variable (name in a specific context) 
with the type.

Of course I get it that you only choose *selected* names to label with 
this name2type mapping. I just don't think this happens often enough to 
make it a language feature, or would be valuable enough when it does 
happen, to make up for the disadvantages.

You're using a *project-wide global* declaration, distant from the 
variable's context, possibly even in a completely different file from 
where the variable is used. That's just about the worst possible way to 
annotate a variable with a type.

But if some, or all, IDEs want to support this, I have no objections. 
Just don't use it in any code I have to read :-)


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

I don't know whether PyCharm does type-inference, but it *claims* to, 
and it does have a plugin which runs MyPy, and MyPy certainly does.

If PyCharm lacks this feature, have you checked out the competition 
(e.g. Wing IDE, PyDev, Spyder)? Have you submitted a feature request? It 
could integrate better with MyPy, or possibly even the new type-checking 
tool from Facebook:

https://pypi.org/project/pyre-check/

or Google's:

https://github.com/google/pytype

Jedi is another project which claims to implement type-inference and 
only require hints as a fallback:

https://jedi.readthedocs.io/en/latest/docs/features.html#type-hinting


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

The point of modules, and functions, is *encapsulation*. If I name a 
variable "spam" in function 1, why *must* a similar variable use the 
same name in function 2 let alone function 202, distant in another 
module? That implies a level of coupling that makes me uncomfortable.

And probably an excess of generic names like "response" and too few 
*specific* names like "client_response" and "server_response".

I am impressed by you and your team's attention to detail at requiring 
consistent names across such a large code base. I don't know if it is a 
good thing or a bad thing or just a thing, but I can admire the 
discipline it requires. I am certainly not that meticulous.

But I'm also faintly horrified at how much pointless pretend- 
productivity this book-keeping may (or not!) have involved. You know the 
sort of time-wasting busy-work coders can get up to when they want to 
look busy without actually thinking too hard:

- prettifying code layout and data structures;
- pointless PEP-8-ifying code, whether it needs it or not;
- obsessing about consistent names everywhere;

etc. I know this because I've wasted many hours doing all of these.

(I shouldn't *need* to say this, but I will anyway: I am making no 
comment on *you and your team* specifically, as I don't know you. I'm 
making a general observation about the tendency of many programmers, 
myself included, to waste time in unproductive "refactoring" which 
doesn't actually help code quality.)

I don't see "inconsistent" names in different functions or modules to be 
a problem that needs to be avoided. Hence, I don't avoid it. I don't go 
out of my way to use unique names, but nor do I try to impose a 
single-name policy.

In any case, we're still up against the fact that in 2018, the state of 
the art in type checkers is that they ought to be able to do what a 
human reader does and infer the type of your variables. It shouldn't 
matter whether you call it "response" or "spam" or "zpaqxerag", if your 
type-checker can't work out that

    foo = HttpResponse(*args)

is a HttpResponse object, something has gone wrong somewhere. Adding yet 
another way to annotate variables instead of improving type-inference 
seems like a sub-optimal choice to me.

https://mypy.readthedocs.io/en/latest/type_inference_and_annotations.html



-- 
Steve