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

[Dennis Brakhane]

Am 15.08.2014 01:56, schrieb Guido van Rossum:

> PS. I realize I didn't discuss question (C) much. That's intentional
-- we can now start discussing specific mypy features in separate
threads (or in this one :-).

So is this the place to discuss "the thornier issues brought up against
mypy"? Because I think it's important that we get an idea of what we
want mypy to be able to do and what
not. After all, mypy will probably end up as a kind of reference
implementation for static type checkers. And I'm worried there might be
real damage to Python as a language
if they aren't thought through:

> Many people have shown either support for the idea, or pointed to some
other system that addresses the same issue. On the other hand, several
people have claimed
> that they don't need it, or that they worry it will make Python less
useful for them. (However, many of the detractors seem to have their own
alternative proposal. :-)
> In the end I don't think we can ever know for sure -- but my intuition
tells me that as long as we keep it optional, there is a real demand.

It won't be optional for programmers who work in a corporate environment
where mypy happens to be required. Those teams will probably also use
third party libraries,
and they might want them to be "type safe" as well and file RFEs for it;
in a few years, we might end up with a situation where "serious" code is
expected to provide static type info.

Even if mypy is "just a linter", a linter is supposed to find bugs and
promote best practices. And if the Python reference doc somehow named
mypy as an example for a static
type checker, it will be probably seen as enforcing Python best practices.

I really think there's a good chance/risk that mypy will change how
Python programs are written in the future. 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.

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.

If we take the current mypy approach, the type system would probably end
up a lot like Java's, useful for simple cases, and useless/a PITA otherwise.

And if we make the system minimal by design, there's a good chance that
it will be completely useless for static type checking for all but the
most trivial cases, helping no one.

I'm not sure which one I prefer, although I'm leaning into the minimal
to Java level direction; that way, the type system might be "just bad
enough" for people to see when
dynamic typing is an advantage and using that instead.


One thing where I do have a clear opinion is that it should/must be
possible to override (bad) type annotations.
Providing a seperate file seems ok to me. But the open problem with this
approach is

1) how to tell IDEs and linters which overrides are in effect when and
where (there might be different override for different modules)

2)how we should handle different versions of libraries

As an example for 2), let's say I'm the author of the frobnicate
library, which depends on spammatron 0.3 from pip.

Let's also say that - because it's a good idea - mypy will check
override modules for consistency: An override cannot declare a
completely different signature than the original.

Spammatro's author declared "def foo(x: float) -> float", but actually,
it should have been "Number" instead of float, as I'm using Decimal. So
I define a override module to fix it.

Now spammatron 0.3.1 is released, and foo has gained an additional
optional parameter: "def foo(x: float, y: float = 0) -> float". So I
have to update my override module, but then my
library isn't compatbile with 0.3 anymore; or at least will give linter
errors.

Providing both overrides would be very difficult; the static analyser
would have to know which versions of the library it is using.

I suppose it could look at the __version__ attribute, but what if it's
missing?