«Утиная» типизация, конечно, ускоряет написание программ, но только до определённых пределов. В больших проектах, когда количество кода достаточно велико, такая гибкость начинает давать сбои. С Python 3.0 можно делать типизацию для функций. Но только с 3.5 появится действительно мощный инструмент, встроенный в язык.
Конечно, можно делать описание параметров и возвращаемых значений в докстрингах. Вот только кто их пишет? А если пишет, то кто следит за их актуальностью? Программисты ленивы: если можно что‑то не делать, они не будут этого делать.
А если уж делать описание типов, то в интерфейсе функции. Так можно и для IDE подсказки получить, и инструментами статического анализа пользоваться (например, mypy). И следить за изменением интерфейса в разы проще. Большие компании делают это уже давно: в больших проектах без этого просто не обойтись.
Если посмотреть, как можно указывать типы в функциях Python 3.0, то становится понятно, что гибкости синтаксиса не хватает для описания даже достаточно часто встречаемых ситуаций. К примеру, совершенно не понятно, как описать принимаемую в качестве параметра функцию: сколько у неё должно быть параметров? Какое возвращаемое значение?
Конечно, можно пользоваться mypy. В нём синтаксической гибкости хватит — если не на все случаи, то на большую часть точно. Но это не часть языка, так что применимо только для кода, который не выйдет за пределы команды. Публичные библиотеки так описывать не стоит.
Хорошо, что появился PEP 484. И он уже вот‑вот станет частью Python.
Жду этих нововведений с нетерпением. Даже поставил релиз‑кандидат, чтобы опробовать нововведения в деле. Впечатления от предложенных нововведений отличные: описания делать удобно и быстро. Читаемость кода не страдает, даже местами улучшается. Пора писать commit‑hook.