PEP 526 - var annotations and the spirit of python

[Steven D'Aprano]

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 at orac ~ $ mypy python/utilities/enhanced_dir.py
python/utilities/enhanced_dir.py:141: error: Module 'types' has no 
attribute 'ClassType'


steve at 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