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

[Gregory P. Smith]

On Fri Aug 15 2014 at 5:46:12 AM Dennis Brakhane <brakhane at googlemail.com>
wrote:

> 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:
>

I'm not concerned about that myself. If this syntax doesn't work out, the
the existing status quo prevails and the syntax is ignored by other tools
that need more than it can provide.

That still leads to the same feedback cycle we already have today such that
the language syntax for type annotations can evolve and improve again in
the future.

[Caution: I'm commenting about mypy below after having spent less than 10
minutes looking at its website to pretend I know what it can and can't do
already. Assume I'm wrong.]

ie: there are things I don't know about mypy.  Does it have the ability to
specify that the return type of "def foo(A, B)" is the same type as
whatever the caller passed in for parameter B?  That is a pretty common
thing in Python.  Even if it doesn't have it today, I suspect it can be
added in the future.

There are other things mypy didn't appear to deal with at first glance
either, specific sets of possible inputs -> outputs rather than always
listing inputs as a union of all possible types for that parameter and
outputs as a union of all possible types to be output.

I may well be wrong about the above.  But even if I'm not, I'm not worried.
Deeper analysis and annotation tools will simply do what they are already
doing: plowing on ahead with their own extended annotation format.

I understand your concerns (in the rest of our message that i've elided)
but I think a "try it and see" approach will actually work here.

Libraries are already released where people have gone overboard with
incorrect overly strict isinstance or issubclass checks. Those are _worse_
than something that merely lists overly strict types as you literally
cannot use them without modifying the code or complying.

Something any code analyzer implementation needs is an ability to be told
"ignore this module, it's full of crap." as part of its analysis process. :)

-gps
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140815/c42b05c7/attachment-0001.html>