On Fri, 06 Jul 2018 09:42:09 +0200, Antoon Pardon wrote: > On 06-07-18 08:17, Steven D'Aprano wrote: >> On Thu, 05 Jul 2018 16:09:52 +0200, Antoon Pardon wrote: >> >>>> This is not an innovation of Mypy. It's how type inference is >>>> supposed to work. If a particular type checker doesn't do that, it is >>>> doing it wrong. >>> That is how type interference works in languages that have some kind >>> of static typing like Haskell. >> No, that's how type inference works in dynamically typed languages like >> Python as well. See Mypy for an example. > > Sorry, but this kind of wording is misleading to me. IMO, it strongly > suggests that we can have type inference in python without losing any of > the dynamism.
That's true in two senses, false in a third. 1. We can have the benefits of static type checking without losing any of the *available* dynamism -- the Python interpreter remains fully dynamic and we can make use of that dynamism by simply *not* type-checking a particular function or module; 2. we can get the benefits of static type checking without losing the dynamism we *actually use*, because in general we don't use much of it (you don't miss what you don't use); 3. but in the third sense, of course you do have to choose to forgo the opportunity for some dynamism in order to get the benefit of static type checking. With gradual typing you can statically check the parts of your code that benefit from it while other parts of the code remain fully dynamic. The bottom line is that every Python programmer can choose for their own projects just how much or how little dynamism is appropriate, trading off the convenience of runtime dynamic typing with the type-safety of static type checking without needing to make an All Or Nothing choice. > The impression that I got from this thread was that you could just trow > any python program through mypy and it would work. Not quite, but you might be surprised. I know I was :-) I just picked a random selection of modules out of my private toolbox, ran mypy over them, and in a few tries found some bugs: steve@orac ~ $ mypy python/utilities/enhanced_dir.py python/utilities/enhanced_dir.py:141: error: Module 'types' has no attribute 'ClassType' steve@orac ~ $ mypy python/excguard.py python/excguard.py:138: error: "str" has no attribute "uper"; maybe "upper"? That's not bad. With absolutely no type hinting, mypy found two bugs in my code from six attempts. And remember, with no type annotations, Mypy is treating all the functions as duck-typed, even if I'm not using them in a duck-typed fashion. If I were to add annotations, I'd probably find a lot more errors. (I don't fool myself into thinking my code is bug-free.) You aren't going to get the full benefit of Mypy without making a commitment to type-hinting at least *some* of your code. Running it over a random Python module with no hints is not going to do much. >> But if you opt-in to using a type-checker, the assumption is that you >> are writing in a less-dynamic, more-static style that will actually get >> some advantage from static type checking. If you're not doing so, then >> you're just annoying yourself and wasting time and you won't enjoy the >> experience one bit. > > Thank you for this clarification. It seems that we are largely agreeing > but I seem to have understood your past contributions differently than > you intended. I may have been a little unclear, if so mea culpa, sorry for any misunderstanding I caused. -- Steven D'Aprano "Ever since I learned about confirmation bias, I've been seeing it everywhere." -- Jon Ronson -- https://mail.python.org/mailman/listinfo/python-list
