[St-Clock]

For our small team, we found that type annotations are useful as a substitute of documentation and it cut our docstrings at least by half. For most small and well-named API functions, we don't need docstrings anymore.

We're big fans of type aliases also. For example, API functions do not return an int, they return a PK. They do not return a str (or Text), they return a URL.

We're also heavy users of typing.Optional to mark parameters or return values that can accept and return None.

We tried mypy but it failed miserably on our large codebase and frankly, with our large test suite, we never had a typing error found in production so I think it's not a good investment of our time.

I'm eager to test type annotations with our next intern to see if it speed up the ramp up process.

[lsh]

Python type hinting and aliases in Python 3: https://docs.python.org/3/library/typing.html

I've just finished porting a small application to Python 3 just because 2020 and deprecation is in sight already - there are so many things that have passed me by in the Py3 world.

[kzrdude]

What I missed first was this deal with provisional API. Nice that it's widely tested, but it should be clear that typing is provisional: Your program is not future compatible if you use it.

Asyncio was provisional until Python 3.6, so it is effectively a Py 3.6 feature that has been backported to 3.5 in time and space.

[Xophmeister]

> we never had a typing error in production

Python (currently) doesn't actually check actual types are per their annotations. Do you mean that you rely on, say, your IDE to do static analysis to ensure everything's lined up, or that just by virtue of having annotations, your team can reason about things more easily?

That's one thing I don't really like about type annotations in Py3.5+, unless you run it through a static analyser or have an IDE that understands them, they're effectively just noise. As such, I have mypy running through Syntastic, in Vim, and while not perfect it's a vast improvement over non-annotated Python.

[St-Clock]

Regarding typing errors in production, I meant that we never encountered an error that could have been directly prevented by a Java-like static type checker[1], e.g., a function with an int parameter that was called with a string argument.

We use types as a documentation tool so the noise you are talking about is actually very useful to us. When someone unfamiliar with the code wants to call a function, a quick look at the signature is usually enough now that we use type annotations. Before that, we provided that information in a docstring, which was more verbose so longer to write and longer to read.

We found PyCharm to offer a better out of the box validation experience than mypy (less configuration), but it's not perfect, i.e., we still see occasional false negatives and false positives. Ultimately, we did not include type checking in our build pipeline, but as the tooling becomes more mature, we will definitively revisit that decision.

[1] I know other languages have more powerful type systems that may have prevented some errors we encountered, but I don't have enough experience with these type systems applied to large systems to comment on that.

[coldtea]

>Regarding typing errors in production, I meant that we never encountered an error that could have been directly prevented by a Java-like static type checker[1], e.g., a function with an int parameter that was called with a string argument.

That's because your devs had already suffered this bug in their test runs once too many times, and killed it before it got to production.

That, and luck.

[St-Clock]

I agree. That is why I mentioned our large test suite in my first comment.