Comments 12
С одной стороны, это скорость разработки: не нужно объявлять и запоминать типы переменных.
Поспорю. В большинстве случаев переменные это некие объекты, а если ты не помнишь или не знаешь тип объекта, то ты не знаешь, какие методы у него есть и как он ведёт себя в разных случаях. Налицо не скорость, а мучение, особенно поддержки. С другой стороны, иногда из самого кода однозначно ясно, какой тип объекта используется, вот тогда можно (было бы) не указывать тип именно для простоты и скорости. Что давно и сделано в других языках.
я покажу, почему type hinting...
К сожалению, это всё ещё именно hinting, а не жёсткое правило. Динамические типы накладывают сложность и на ран-тайм и на сами объекты, ведь ничего просто так не даётся. А зачем? Кроме задачек школьного уровня, непонятно.
С линтерами основанными на тайпхинте так и работает. Тип выводится из контекста.
Линтер встроен в редактор кода? А если это diff в ревью пулл-реквеста? А если просто смотрю код в vim или FAR? Нет, IDE это одно, а легко читаемый код, это другое.
Кроме того, когда смотришь код методов и бегаешь по нему, замучаешься тыкать мышкой везде, чтобы узнать, что линтер там навыводил. Код должен быть понятен без линтера.
не всегда хочется смотреть реализацию какой либо функции, чтобы определить тип возвращаемого значения) Да, hinting - не жесткое правило (как и многое в Python), но такие мелочи, по моему мнению, упрощают дальнейшую поддержку кода и помогают избежать "глупых" ошибок, особенно если использовать mypy. Но, опять, же стоит исходить из особенностей вашего проекта
не всегда хочется смотреть реализацию какой либо функции, чтобы определить тип возвращаемого значения)
А это тут при чем? Я разве против объявления типа возвращаем ого значения? Я наоборот, двумя руками за.
особенно если использовать mypy. Но, опять, же стоит исходить из особенностей вашего проекта
Сегодня у вас mypy, завтра что-то другое. А diff вы все равно смотрите так, что мышкой ни на что не потыкаешь, чтобы узнать реальный тип объекта.
Есть разные проекты, разные редакторы, разные фирмы, разные случаи, разные правила. Поэтому понятный код, он и в Африке понятный, независимо ни от чего.
Вот просто по ощущениям:
Когда я пишу программу на компилируемом языке я пишу программу. Я проектирую типы как утверждения о данных, пишу сигнатуры функций как правила преобразования. Всё чётко и прогнозируемо. Я её закончу и она будет жить долго и счастливо.
Когда я пишу на некомпилируемом языке я просто пытаюсь пройти до конца и получить нужный результат один раз. Я буду ему помогать в отладчике, подталкивать, пришивать заплатки. Он один раз дойдет до конца. О, на часах уже 3 ночи! Я вздохну, вытру вспотевший лоб уставшей рукой и скажу: "Ну, с богом на прод! Будет работать, наверное!"
Какой нибудь data science, где почти нет общих правил или есть с кучей граничных случаев (corner cases) все эти типы нафиг не работают. Но там где ответственная бизнес логика типы должны быть, сильная статическая типизация и компиляция.
И начинать писать с без типов, набирая сотню тестов, а потом добавлять типы, выражающие общие для всех тестов правила - прохладная такая практика. Наоборот, лучше найти общее правило и выразить его в типе. Пусть даже потом оно обрастет исключениями, правило поможет.
Так а почему ни слова о том, чем эти хинты теперь проверять? Или все по дефолту вместе с IDE получают проверку типов? Инструментов много, статья без них не особо полезна.
Статья устарела, с 3.12 синтаксис и хинтов и дженериков поменялся. Теперь половина пишется по новому и удобнее, половина по старому.
"Очень удобно и консистентно прошу заметить. "
Очередные костыли к костылям, используйте нормальные языки, если доросли до типизации
От python и аннотации типов до TS и JS один шаг )
Типизация в Python: как аннотации спасают ваш код и ускоряют разработку