Type checking in Python

I believe that dynamic typing results from frustration over generics, rather than over static typing in general. (Type stuttering is another problem, but modern languages solve it with local type inference.) I mean, annotating non-generic functions is always straightforward doesn't introduce much complexity:

    # s should be str
    # returns nothing
    def print(s):
        ...

    # just becomes (using Py3 annotation syntax)
    def print(s: str) -> None:
        ...

    # for any types t0, t1, t2, ... tn:
    # fn is a function that takes arguments of types t0, t1, ... t(n-1)
    # and returns a value of type tn;
    # seqs are iterables of types t0, t1, ... t(n-1);
    # returns a list of type tn.
    def map(fn, *seqs):
        ...

    # How to write this signature is non-obvious

That's when the dynamic typing people get annoyed and go "fxxk static typing systems, I can handle this in my mind". Which is about 65% (totally random estimation) the point of dynamic typing in my opinion.

Any type checker for dynamic typed languages that doesn't seriously try to solve the generics problem is not genuinely interesting.

The article says that the lack of type checking "lets through" a certain class of errors. However, let's be specific here: there is no build-time static analysis phase in the transformation of python source to executable code. So "lets through" means the same thing whether you have strong typing or not: the error is going to be found at runtime. What we're really talking about, then, is converting AttributeError ("YourObject has no attribute 'startswith'") into something more specific ("Hey, this is supposed to be a string!"). Honestly, that seems to me to be a pretty minor increase in diagnostic information.

So the bottom line for me is that I feel I didn't really understand duck typing. I used to joke that the term actually meant "no typing," and that is in some respects true. But what it really means is "the thing can do what the method expects it to be able to do." If the thing can't serve in the expected role, then the existing errors that result are sufficiently explanatory, imo.

I would rather see a more generic pre/post-condition contract system, to be used in select top-level functions, that gives a lot more flexibility in expressing what is supposed to happen (i.e. I expect to be given a not-None value with a __str__ method that doesn't throw and will return an iterator yielding consecutive not-empty, not-None strings), including what assumptions you're making when you call a function that you got from a random object (i.e. here I'm calling a function that I got somehow as a parameter and I'm going to assume it can take a string of the format "ipv4 address:port" and returns an object that is a database connection), together with a mechanism for recovering from broken contracts - we are doing runtime checks, so there's no reason to restrict ourselves to Java-style type constraints, which don't even work for Python in general. Or, alternatively, a lighter system that can be checked at import time once before the program is started "for real". Preferably both of those.

The closest I've seen is the traits thing from Enthought, but there doesn't seem to be much buy-in from python users.

Turns out with modern tools you _can_ statically type check python :)

I wish there was something like this, but parsing the docstrings with the same format as pycharm: http://www.jetbrains.com/pycharm/webhelp/type-hinting-in-pyc...

    @returns(int)
    @params(a=int, b=int)
    def add(a, b):
        return a + b

    @typ(int, int, ret=int)
    def add(a, b):
        return a + b

Senko's version has the advantage that you can compose types in it, e.g. {str:int} is a dictionary whose keys are strings and values are integers.

    @ensure_annotations
    def f(x: int, y: float) -> float:
        return x+y

    f(1, 2.3)
    >>> 3.3
    f(1, 2)
    >>> ensure.EnsureError: Argument y to <function f at 0x109b7c710> does not match annotation type <class 'float'>

When function annotations were introduced, I ended up removing all their uses from the standard library because every early attempt to use it was too simplistic and failed to support any type-system use case except for extra documentation.