Для меня этот код выглядит бессмысленным, потому что аннотации и так позволят отловить ошибки даже без запуска кода. А если кто-то вздумает пихать в функцию какой-нибудь Any — так надо не pydantic тащить, а от Any избавляться
Не совсем. Оба примера это по сути взаимодействие с внешним миром (нетипизированная функция это по сути тоже «внешний мир» по отношению к TS), а поскольку TS не способен гарантировать безопасность внешнего мира, то обеспечением этой самой безопасности заниматься должен уже программист (написать проверки типов и так далее). А во «внутреннем мире» в корректно аннотированном TS-коде без any вы такое провернуть уже не сможете.
Наверное, можно предъявить TS претензию, что он использует опасный any вместо чего-то наподобие ключевого слова unsafe как в других ЯП, но по крайней мере в typescript-eslint есть правило no-unsafe-assignment, запрещающее пихать any куда попало, так что в принципе оба примера можно отловить и больно надавать реализовавшему их программисту по рукам
Проверять корректность аннотаций в рантайме никому не надо (и в python так тоже не делают), а вот поддержка синтаксиса скорее всего будет https://tc39.es/proposal-type-annotations/
меняя строку на объект во всех местах, где она встречается.
Но TypeScript или иной тайпчекер заботливо высыпет мне список всех мест, где это нужно сделать, и мне не придётся искать их вручную (правда, места с неявными преобразованиями в строку всё равно создают проблему, это печально)
с поиском по всей кодовой базе
Опять же — искать буду не я, а TypeScript
вместо одной строки может прийти другая строка - TS это спокойно схавает.
Поэтому особо упоротые по типам идут ещё дальше и заводят по отдельному типу для каждого отдельного вида строк (и для каждого отдельного вида чисел, чтобы нельзя было случайно сложить килограммы с метрами и так далее) — но это уже другой уровень, которого лично я пока ещё не достиг
Если компилятор плюнул — это замечательно, потому что такую ошибку быстро, легко и дёшево исправить, и она даже в коммит в репозитории не успеет попасть.
Если какая-то проверялка типов выплюнула ошибку в рантайме из-за того, что бэкенд внезапно прислал вместо числа строку — чуть менее приятно, но по крайней мере очевидно, в каком конкретно месте испортился тип и где это исправлять.
Когда толпа пользователей прибегает жаловаться, что две книги по 9 в сумме стоят 99 — это катастрофа: техподдержка перегружена, чудовищный репутационный ущерб, и нужно срочно как-то найти, в каком конкретно месте число превратилось в строку (совсем не факт, что виноват именно бэк), и исправить желательно вчера
И сделаю я это только в тех местах, где потенциально может быть неразбериха с этими типами.
То есть доверитесь человеческому фактору, который может что-то упустить, вместо бездушной машины, которая гарантированно и неотвратимо проверит вообще всё и везде? Не понимаю я такой мазохизм...
Никто не говорил, что он очень нужен в проектах, где 5 или даже 15 человек.
А потом однажды обнаруживается, что в команде уже 200 человек, из которых никто не может ответить, author это строка или объект (или, может, вообще числовой id, а может разные варианты в зависимости от контекста), потому что программист, создававший этого authorа, уволился ещё пять лет назад, и в итоге команда сидит и ищет, откуда этот author в принципе может прилететь в пределах всей кодовой базы. Так что, имхо, лучше с самого начала делать всё с аннотациями
Ну а впрочем ситуацию с бэком и фронтом тоже можно рассмотреть. Вот допустим изначально с бэка прилетает информация об авторе поста в виде строки с никнеймом, но потом бэк решает добавить больше информации и меняет строку на объект с инфой (аватарка, карма и т. п.), нарушая обратную совместимость. Как, не проверяя типы по всей кодовой базе, разработчик фронта может быть уверен, что он не забыл поменять условное author на author.nickname везде где надо? Компенсировать отсутствие типов 100% покрытием тестами или есть более адекватные варианты?
"Вы просто не работали с очень крупными проектами"
Вот да, у меня есть несколько некрупных проектов, которые с годами случайно вырасли в крупные, и теперь вот сижу и думаю, как их рефакторить, потому что без аннотаций типов на код теперь даже дышать страшно - совершенно непонятно, что откуда прилетает и всегда ли оно прилетает, куда улетает и какие типы ожидает
Значит вы не работали с реальными данными в реальных проектах. Прилёт номера вместо строки - вполне обычное явление, и перед работой нужно проверить, что номер является номером, и typescript заставит это проверить (если не лепить any куда попало) - чем он и прекрасен
С учётом того, как делаются современные фронтенды, предположение про кэш является чушью
Спустя неделю всё по-прежнему сломано
Это вроде как решили в UUIDv7
Вот пример из моего личного опыта — в Manticore нельзя, максимум 64 бита
Для меня этот код выглядит бессмысленным, потому что аннотации и так позволят отловить ошибки даже без запуска кода. А если кто-то вздумает пихать в функцию какой-нибудь Any — так надо не pydantic тащить, а от Any избавляться
Не совсем. Оба примера это по сути взаимодействие с внешним миром (нетипизированная функция это по сути тоже «внешний мир» по отношению к TS), а поскольку TS не способен гарантировать безопасность внешнего мира, то обеспечением этой самой безопасности заниматься должен уже программист (написать проверки типов и так далее). А во «внутреннем мире» в корректно аннотированном TS-коде без any вы такое провернуть уже не сможете.
Наверное, можно предъявить TS претензию, что он использует опасный any вместо чего-то наподобие ключевого слова unsafe как в других ЯП, но по крайней мере в typescript-eslint есть правило no-unsafe-assignment, запрещающее пихать any куда попало, так что в принципе оба примера можно отловить и больно надавать реализовавшему их программисту по рукам
Проверять корректность аннотаций в рантайме никому не надо (и в python так тоже не делают), а вот поддержка синтаксиса скорее всего будет https://tc39.es/proposal-type-annotations/
Почему? Это может быть осознанное и задокументированное изменение в API, и задача фронтенда — научиться работать с этим изменением.
Собственно, наивность и рейтинг ваших комментариев ещё раз демонстрируют, что с реальными проектами вы не особо работали)
Но TypeScript или иной тайпчекер заботливо высыпет мне список всех мест, где это нужно сделать, и мне не придётся искать их вручную (правда, места с неявными преобразованиями в строку всё равно создают проблему, это печально)
Опять же — искать буду не я, а TypeScript
Поэтому особо упоротые по типам идут ещё дальше и заводят по отдельному типу для каждого отдельного вида строк (и для каждого отдельного вида чисел, чтобы нельзя было случайно сложить килограммы с метрами и так далее) — но это уже другой уровень, которого лично я пока ещё не достиг
Если компилятор плюнул — это замечательно, потому что такую ошибку быстро, легко и дёшево исправить, и она даже в коммит в репозитории не успеет попасть.
Если какая-то проверялка типов выплюнула ошибку в рантайме из-за того, что бэкенд внезапно прислал вместо числа строку — чуть менее приятно, но по крайней мере очевидно, в каком конкретно месте испортился тип и где это исправлять.
Когда толпа пользователей прибегает жаловаться, что две книги по 9 в сумме стоят 99 — это катастрофа: техподдержка перегружена, чудовищный репутационный ущерб, и нужно срочно как-то найти, в каком конкретно месте число превратилось в строку (совсем не факт, что виноват именно бэк), и исправить желательно вчера
То есть доверитесь человеческому фактору, который может что-то упустить, вместо бездушной машины, которая гарантированно и неотвратимо проверит вообще всё и везде? Не понимаю я такой мазохизм...
По крайней мере он хотя бы не позволит внезапно заменить число на строку:
Хотя я сейчас понял, что продолбался с примером и от неявного преобразования объекта в строку TypeScript всё равно не спасёт:
Однако обычный JavaScript от такого тоже всё равно не спасёт)
Впрочем, можно прикрутить какой-нибудь плагин к какому-нибудь линтеру, я надеюсь?
А потом однажды обнаруживается, что в команде уже 200 человек, из которых никто не может ответить,
authorэто строка или объект (или, может, вообще числовой id, а может разные варианты в зависимости от контекста), потому что программист, создававший этогоauthorа, уволился ещё пять лет назад, и в итоге команда сидит и ищет, откуда этотauthorв принципе может прилететь в пределах всей кодовой базы. Так что, имхо, лучше с самого начала делать всё с аннотациямиНу а впрочем ситуацию с бэком и фронтом тоже можно рассмотреть. Вот допустим изначально с бэка прилетает информация об авторе поста в виде строки с никнеймом, но потом бэк решает добавить больше информации и меняет строку на объект с инфой (аватарка, карма и т. п.), нарушая обратную совместимость. Как, не проверяя типы по всей кодовой базе, разработчик фронта может быть уверен, что он не забыл поменять условное
authorнаauthor.nicknameвезде где надо? Компенсировать отсутствие типов 100% покрытием тестами или есть более адекватные варианты?Поработаете в крупных проектах без typescript - потом прибежите в эту ветку плакаться, что как же я был прав :)
Нет, сторонние компании, с которыми я обмениваюсь данными, никак не относятся к проекту (и некоторые даже не знают о существовании моего проекта)
С чего вы вообще взяли, что речь о бэке и фронте? Ещё раз, речь о ВНЕШНИХ данных, которые вообще не мои и создаются не мной
"Две книги по [object Object] рублей, итого NaN рублей"? Спасибо, не надо
Изначально речь не о коде, а о ВНЕШНИХ данных, которые я НЕ контролирую
В том, что мне нужна не строка, а число
Вот да, у меня есть несколько некрупных проектов, которые с годами случайно вырасли в крупные, и теперь вот сижу и думаю, как их рефакторить, потому что без аннотаций типов на код теперь даже дышать страшно - совершенно непонятно, что откуда прилетает и всегда ли оно прилетает, куда улетает и какие типы ожидает
Значит вы не работали с реальными данными в реальных проектах. Прилёт номера вместо строки - вполне обычное явление, и перед работой нужно проверить, что номер является номером, и typescript заставит это проверить (если не лепить
anyкуда попало) - чем он и прекрасен