[Python-ideas] Optional static typing -- the crossroads

[Steven D'Aprano]

On Fri, Aug 15, 2014 at 02:37:45PM +0200, Dennis Brakhane wrote:

> I really think there's a good chance/risk that mypy will change how
> Python programs are written in the future.

I certainly hope so. We're wasting our time if it doesn't. Why go 
through all the time and effort if nobody uses it?


> For example, people wouldn't probably call the word_count method with 
> a file object and write a test case, instead, they will read the file 
> into a list and call it instead. After all, the linter would complain 
> otherwise.

How do you know the linter will complain?

Many of the arguments against this proposal are based on the assumption 
that, given a type checker for Python, developers will suddenly abandon 
all the proven advantages of duck-typing and dynamic typing and rush to 
turn Python into a third-rate Java. I don't think this is a realistic 
fear. The mere fact we are having this argument proves that many Python 
developers will fight tooth and nail to keep using duck-typing and 
dynamic typing. If they do static type checks, they aren't going to give 
up those advantages. They'll check for Iterable, not list.

And those who don't? Do the same thing you would do *right now* when 
those authors write code like this:

    if type(argument) is not list:
        raise TypeError("list expected")


Report it as a bug, or request a feature enhancement. Patch the library. 
Use a different library. Or, *just don't use the linter*.


> IMO, the question is how much "staticness" we want to encourage. If we 
> want a really useful and flexible static type checking system, we 
> would need a very complex type system. If we'd go that route, I fear 
> that one of Pythons main features, its dynamic nature will be seen by 
> new programmers as kind of "deprecated legacy", and turning Python 
> into some poor-man's-Scala.

Static typing and dynamic typing are *not* opposites. The names are 
unfortunate, because they imply an opposition that doesn't necessarily 
exist. Both static and dynamic typing are attempts to solve certain 
problems in programming, and it is possible to do both at the same time.


[...]
> One thing where I do have a clear opinion is that it should/must be
> possible to override (bad) type annotations.

Why? Do you consider it a "must" to override functions that raise 
TypeError at run time?

py> len(None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: object of type 'NoneType' has no len()

So why do you consider it a "must" to be able to override functions that 
report type errors at compile time?

But for what it's worth, as this proposal has repeatedly said, the 
linter is optional. If you don't believe the linter, *just run the code* 
in Python like you have always done before.


-- 
Steven