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

[Dennis Brakhane]

On 15.08.2014 18:35, Gregory P. Smith wrote:
>
> 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.
>
I agree.

> 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.
>
> 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.
That's a good example of what I'm worried about: to be really useful,
the type declarations have to be really flexible. My (maybe irrational)
fear is that we end up with a turing complete type system.

If a programmers needs to spend 10 minutes thinking about how exactly he
has to declare his method parameters or "class interfaces" (does my
container type behave covariantly or contravariantly?), and all that
just so his code passes a linter, something went wrong ;)

We shouldn't try to make the signatures carry all information needed for
type checkers, if some things can only be found out by code analysis,
that's fine by me.

For example, Jedi can handle the following silly example:

def foo():
  return [os, sys]

x = foo()


Jedi knows that x[1] is sys and will only propose members of sys, and
only os members for x[0]. And the linter of the current development
version will actually barf on x[1].walk():

/tmp/a.py:12:5: E1 AttributeError: <CompiledObject: <module 'sys'
(built-in)>> has no attribute walk.

Trying to get this kind information encoded into some kind of type
signature would be insane, IMO.