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

[Anders Hovmöller]

I'll just simply reply here that Mypy on our entire code base just silently outputs nothing. Nothing at all. I tried to look at the code to find out why and maybe implement the name checking feature discussed here and was terrified by the Byzantine complexity of the code base. I gave up. 

From what I later understood of Mypy it is supposed to be used to check all types or none on a file level, not just check what can be checked so you can gradually add typing in reasonable places. This seems the totally wrong approach to me. I think we agree on this point. 

As for why we have consistent names, it was before my time but keeping this consistency isn't much work, we certainly don't go back and change code to enforce conventions. 

> On 23 Oct 2018, at 01:02, Steven D'Aprano <steve at pearwood.info> wrote:
> 
> 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
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/