Я ожидаю от сервера число и два массива длины, соответствующей этому числу.
Намекаете, что в любом статическом языке так можно? Или просто стартуете новую тему? Если новую тему, то, сомневаюсь, что в питоне так можно. Если и можно, мне об этом неизвестно.
Подозреваю, что поэтому у вас MyPy не взлетел — ваш подход к решению задач совсем иной.
Такую помойку в сигнатурах вообще не люблю, вся она остается за стенами адаптера, который сразу преобразует к нормальному типу, который и дает все нужные гарантии. Передавать между слоями наборы массивов хештейблов, это не для меня.
У меня обычно если такое требуется передавать между слоями, там интуитивно напрашивается сущность/таблица сущностей. Ну то есть, в теории можно конечно обмазываться аннотациями типа «6 строк длинною 2 через символ :», но по-моему проще сделать сущность MacAddress и доверять ей на основе валидации в конструкторе, или еще как. И да, это разумеется никак не компенсирует отсутствие зависимых типов. Если их подвезут в питон, я в принципе не буду против, и возможно даже где-то буду их применять (в адаптерах например)
Вы ведь понимаете, что линтеры — это такой маленький кусочек статической типизации
Понимаю, я об этом и говорю. Линтеры подарили мне статическую типизацию, сохранив динамику в рантайме. Слава линтерам!
Нет, не понимаю, потому что это не так. Не нужно там везде расставлять типы.
Тут вся беда в том, что вы опять путаете, что под капотом, а с чем работает программист. Я еще раз повторю, мне важна типизация снаружи, а не внутри. Если язык по желанию позволяет не указывать тип — это элементы динамической типизации в статическом языке. И я одобряю это.
У меня в коде есть только аннотации top-level-функций или биндингов, и я почти никогда не пишу аннотации типов локальных для top-level-функций вещей.
Это здорово. Вы полностью описали мой подход к типизации в динамическом языке, который я использую в своих проектах. Может мы об одном и том же говорим? Просто вы так делаете на статическом, а я на динамическом. Быть может, не так на самом деле важна типизация под капотом, раз мы с вами делаем это одинаково?
Нет, мой тезис в том, что статические типы нужны и полезны, а динамические метки и их проверки (почти всегда) не нужны и неполезны (потому что бьют по производительности, как минимум).
Ну тут я уже отвечал, но вы мне не поверили. Вы убеждены, что нет задач, которые бы в динамике решались проще и быстрее, доказать на кошках я это не смогу, поэтому не могу дальше спорить.
Кстати, про производительность согласен. Но это отдельный разговор.
То есть, понятно, что можно взять питон, начать с ним героически воевать [...] Но зачем, если можно сразу взять нормальный статически типизированный язык?
На это я тут уже отвечал несколько раз. Опять таки, если вы не верите в предыдущий мой ответ, на это тоже я не могу отвечать.
Вот этот код статический или динамический?
А вот тут до меня дошло, в чем я не прав, спасибо. Я не упомянул, что говорю о статических ООП языках типа явы или шарпа. Мне то не хватало в них чтобы без лишних усилий можно было на лету менять свойства, методы, инжектить свой код в неприличные места в экстренных ситуациях. Но вы же в хаскель практикуете, а я признаться, не знаю, зачем в ФП языках может понадобиться динамическая типизация.
Во-первых, мы тут обсуждали статическую типизацию против динамической
Возможно вы веткой ошиблись. Изначально в своем первом коментарии я поднял тему комбо-типизации, чтобы как раз не спорить, что лучше, а что хуже, а использовать преимущества обеих.
Идея, что в моём коде будут существовать термы, тип которых компилятору неизвестен и им не проверяется, мне не нравится.
Это все объясняет. И многие предыдущие вопросы тоже. Вам важно, что происходит в компиляторе, мне — нет.
Вы хотите примеров, не вникая в архитектуру? Все такие оторванные от контекста примеры на конях в вакууме выглядят глупо, никогда не убеждают собеседника и решаются элементарно.
Я бы тоже мог попросить у вас примеров таких задач, с которыми не справляется MyPy, а потом решить ее на простых и читаемых типах. Но мы так просто будем бесконечно по очереди углубляться в примеры.
В динамической типизации для быстрого и эффективного решения или отладки я могу вешать в любых местах архитектуры хуки, делать абсолютно прозрачные подмены чего угодно на лету. Если такое реализовано в каких-то гибких статических языках, то явно этот язык уже не такой уж статический (снаружи), и мне вполне подходит.
Хорошо, если в этот аргумент вы не верите, тогда мне нечего ответить.
В любом случае, я тоже могу ошибаться. Языков так много, и возможно мы просто сравниваем неудачные и удачные случаи на неудачных и удачных языках в неудачных или удачных проектах.
Но я убежден, что гибкие высокоуровневые языки в современном мире должны предоставлять возможность указывать тип и возможность творить магию, динамический ли это язык, или статический.
Нет, это так не работает. Нельзя что-то доказать наполовину.
А я ничего и не доказывал, но раз вы хотите: из пункта А выезжает неизвестная переменная (это может быть чужая либа без аннотаций, или HTTP-API, что угодно), где она проходит валидацию в адаптере на этапе рантайма. Адаптер на входе имеет неизвестный тип, а на выходе уже известный, что и отмечено в аннотации. Дальше между нашими слоями мы доверяем этой аннотации на основе доверия адаптеру.
Только не надо говорить, что проще взять сразу статический язык, я на это уже тут несколько раз отвечал.
Конечно, ведь не существует в мире крутых качественных проектов, где под капотом динамика. Ровно как и не существует плохих глючных проектов, написанных на статике. Практика бывает разная, и каждый оценивает через призму своего опыта. У вас такой опыт и такая статистика. Я же просто призываю людей быть объективными и выключить фанатизм.
Мне рабинович рассказывал, что программа, которую он написал на Java, постоянно тормозила и глючила. С тех пор я знаю, что статическая типизация плохая. Извините. Я просто не понял к чему вы это написали. Давайте точнее, прям так и скажите: «я увтерждаю, что все линтеры плохие и не способны работать со сложными типами». А потом еще добавьте: «Поэтому динамическая типизация плохая»
И работе над type hints в питоне уже вроде как много лет, а даже куча библиотек из «включённых батареек» всё ещё неаннотированна.
И в этом виновата конечно же динамическая типизация? Вы же понимаете, что в случае со статической типизацией, к каждому программисту приставлен человек с пушкой, который следит, чтобы тот везде расставил типы. Если к динамическим программистам приставить такого же наблюдателя, они бы тоже расставили везде типы. То есть ваш тезис в том, что все дело в необходимости контроля ленивых программистов, да?
Это проблема не динамической типизации, а дисциплины. Динамическая типизация позволяет хулиганить, статическая — нет. И из этого нельзя делать ложные выводы, что ВСЕ динамические программисты хулиганы, а ВСЕ статические программисты — молодцы. С таким же успехом можно задвинуть глупый вывод, что статические программисты без ошибок на этапе компиляции тоже бы хулиганили, забивая на типы. Но это неправда, и мы таких глупых выводов делать не станем. Давайте не будем делить мир на черное и белое и соскакивать на другие темы.
Тут что ли тоже путаница между неявными аннотациями типов и отсутствием статических типов?
Это у вас путаница между тем, что что важно компилятору, и тем, что важно программисту. Мы тут рассматриваем то, с чем приходится работать лично мне, а не компилятору. А мне приходится работать с кодом. Статический это код под капотом или динамический, мне по барабану, если он позволяет в одних местах делать все строго и статично, а в других свободно и динамично.
Чтобы вы перестали скатываться в другие темы, я еще раз хочу напомнить, что говорю я не про конкретные реализации чего-либо, а про саму идею опциональной типизации с точки зрения взгляда программиста. Вам сама идея не нравится? Или в чем вы меня пытаетесь убедить?
Мне по наследству достался прекрасный проект, обильно обмазанный динамичностью и полным отсутствием типов. Вплоть до того, что объекты одного семейства имели разные наборы методов. Сейчас я все это рефакторю, знаете какой это ад? Я чувствую себя настоящим героем. Но почему-то вы не можете поверить, что по мере рефакторинга код становится читаемым, в среде появляются подсказочки, а в рантайме перестают вываливаться ошибки, что метод отсутствует или переменная не определена.
Если IDE легко… это просто означает, что в программе никакого динамизма и нет вовсе.
Полностью согласен! Но вы видимо решили, что проект — это какой-то монолитный кусок кода, возможно даже в одном файле, что он либо черный, либо белый. Но это никогда не так. Проект может состоять из статического кода, с вкраплениями некоторых динамических модулей, которые офигенно упрощают жизнь, внутри которых аннотации уже не работают (в силу динамической магии), но снаружи имеют статический фасад. Такие модули в статическом виде порой реализовать либо очень затратно, либо вообще невозможно. Сделать статический фасад в этом случае эффективнее.
Можно было бы тогда взять просто статически типизированный язык, и тем самым воспользоваться уже имеющейся проверкой типов и преимуществами с Type-Driven Development.
Еще раз повторю (я уже устал, правда): просто взяв статический язык, вы полностью лишаете себя динамичности (об этом ниже), которая иногда очень выручает. Иногда нам нужно сначала быстро решить проблему, а уже потом решить хорошо, это реальность. Так вот динамичность позволяет творить невероятную магию.
В статической типизации вы либо лишаете себя этой магии, либо язык пытается ее каким-то образом реализовать, отвечая на запрос сообщества. А раз он пытается реализовать динамичность, то «можно было бы тогда взять просто динамический язык» (с)
Я не против статичности или динамичности, я против фанатизма.
я вам абсолютно точно так же напишу решение со строгой типизацией, которое их будет обрабатывать
Только ненужного кода, может получится больше. Не то, чтобы у меня кодофобия, но если лишний код мне никак не упрощает жизнь, я бы предпочел его не писать.
Так я о том и толкую! Ну то есть различия конечно есть, но в контексте этого вопроса, ничем не отличаются.
Скорее минусы обеих. Посмотрите на драму с актиксом
Что есть актикс? Ничего не понял. Не могу ответить.
Ну а дальше по вашему тексту, я думаю мы спорим ни о чем. Вы доказываете, что зебра черная в белую полоску красивее, чем белая в черную полоску. Вы меня ни в чем не убедили, я и так всегда считал важным наличие типизации, просто раньше когда я писал на статических языках, возможно типы нужно было указывать везде. Теперь я знаю, что в статических языках стало попроще с типами. Но так же я знаю, что и в динамических стало получше с аннотациями.
Благодаря этому, роль статической типизации размывается, и мы можем позволить себе выбирать язык по другим факторам, расширяя круг поиска.
Которые есть типы, прикрученные сбоку к языкам, которые изначально не были задизайнены с учётом такой возможности (что в итоге всегда получается плохо). В чём выигрыш?
1. Очень сильно преувеличиваете.
2. Выигрыш был описан ниже сразу после этих слов.
компилятор их часто может вывести
И линтеры динамических языков часто сами могут вывести типы в локальных участках. Только причем тут это? Мы не о линтерах, а об идее рассуждаем.
Я сторонник идеи что аннотации превращают динамический язык в статический в нужных местах и не превращают в ненужных. Если вы противопоставляете этой идее свою идею, что в статическом языке тоже можно скрыть типы в локальных участках, то я совершенно не против такого механизма. Я думаю, он хорош.
Если есть статический язык, в котором статичность везде опциональна, а не только в локальном контексте, я только за, потому что хотелось бы самому решать.
По моему опыту как раз при динамической типизации писать приходится больше. Потому что приходится тестировать то, что в статических япах проверял компилятор.
Нет, не приходится. Уже давно есть аннотации, которые решают вашу проблему на этапе написания, а не рантайма.
Таким образом достигается комбо преимуществ статической и динамической типизаций. Аннотациями можно полностью покрывать швы. А в локальных участках, где срок жизни какой-то переменной составляет 5 строчек, типизация почти никогда не требуется, особенно, если использовать правильные названия идентификаторов типа attempts_count (попробуете угадать тип?). И даже если по имени тип непонятен, просто поднимите взгляд на пару сантиметров вверх (это на крайний случай). А уж если вы хотите попыткам добавить разных таймаутов, то попробуйте вот это переписать на сишарп (вы же на нем пишете?):
for timeout in [1, 3, 10]:
...
Казалось бы, это все мелочи, но их такое огромное количество, что из них состоит половина кода, что мы пишем.
Кроме того, в такой комбо-типизации значительно упрощается прототипирование. Я могу хоть 10 раз переписать какой-то новый для меня механизм в ходе изучения, а уже готовому варианту расставить типы.
Сам я начинал со статической, и потом несколько раз пытался на нее вернуться, потому что мне реально ее не хватало. Но аннотации меня спасли, и мне стало даже лучше.
И прежде, чем со мной спорить, попробуйте меня понять, вы же видите, что я не фанатик, и не делю мир на черное и белое.
А аннотации или тайп хинтинг вы не используете? А то у меня есть подозрение, что IDE вам не подсвечивает типы, и при попытке это исправить, вы вернетесь к циклическим импортам. Но я могу ошибаться. Можете рассказать об этом?
Какие же например в пайтоне использовать циклы для получения индекса?
А зачем вообще другой цикл использовать, если благодаря наличию универсальных механизмов enumerate, range, zip, slice и т. д., можно гибче, и при этом не сложнее, получить больше комбинаций применения?
Речь о том, что тот же zip или slice можно использовать не только в циклах. Так зачем запоминать семантику двух разных подходов (for и foreach), когда и циклы, и остальное, можно положить поверх одного for, применяя вспомогательные простые универсальные механизмы, которые касаются не только циклов?
Type hints — всё-таки совсем не статическая типизация
Я и не говорил, что это статическая типизация, я сказал, что хинтинг решает описанные вами проблемы, попутно избавляя от проблем статической типизации (бойлерплейт в ненужных местах)
Когда начинаются вещи вроде «список кортежей, в которых лежат инты со словарями», поведение объектов при применении вроде бы простых операций становится неочевидным. Да, это расплата за попытку сделать «удобно» вместо «строго». Поведение списков, объявленных как []*x, — пожалуй, Ниагарский водопад в этом мире текущих абстракций.
Это проблемы не в динамической типизации, а в сложных структурах и сигнатурах методов. Покажите пример таких структур, которые элегантно описываются в статической типизации, и невозможно было бы описать хинтингом (и как часто у вас такая ситуация возникает?).
Но в целом Python со своей основной задачей (заменить шелл-скрипты) прекрасно справляется
Так можно было сказать о самых первых примитивных версиях питона. Сейчас же он слишком далеко ушел, чтобы даже упоминать о шелл скриптах.
Можно потратить в 5 раз меньше времени на разработку на языке с динамической типизацией, а потом в 10 раз дольше дебажить результат, чем на статически типизированном языке.
А можно потратить в 10 раз меньше времени на разработку на языке с динамической типизацией, а потом в 5 раз дольше дебажить результат, чем на статически типизированном языке.
Смотрите, я тоже могу цифры выдумывать.
На динамической типизации я могу использовать хинтинг там, где требуется, и не использовать там, где не требуется (например в локальных переменных метода или в каком-нибудь JSON-ответе с сотней полей от кривого стороннего API, из которого мне нужно только одно поле, мне вообще не нужна типизация). Хинтинг решит, описанные вами проблемы и избавит меня от бойлерплейта. При этом упрощается любая динамическая магия и метакод.
Короче в чистом виде и динамическая, и статическая типизация — это для меня неудобно. В идеале, я хочу, чтоб у меня был выбор.
Подозреваю, что поэтому у вас MyPy не взлетел — ваш подход к решению задач совсем иной.
Такую помойку в сигнатурах вообще не люблю, вся она остается за стенами адаптера, который сразу преобразует к нормальному типу, который и дает все нужные гарантии. Передавать между слоями наборы массивов хештейблов, это не для меня.
У меня обычно если такое требуется передавать между слоями, там интуитивно напрашивается сущность/таблица сущностей. Ну то есть, в теории можно конечно обмазываться аннотациями типа «6 строк длинною 2 через символ :», но по-моему проще сделать сущность MacAddress и доверять ей на основе валидации в конструкторе, или еще как. И да, это разумеется никак не компенсирует отсутствие зависимых типов. Если их подвезут в питон, я в принципе не буду против, и возможно даже где-то буду их применять (в адаптерах например)
Тут вся беда в том, что вы опять путаете, что под капотом, а с чем работает программист. Я еще раз повторю, мне важна типизация снаружи, а не внутри. Если язык по желанию позволяет не указывать тип — это элементы динамической типизации в статическом языке. И я одобряю это.
Это здорово. Вы полностью описали мой подход к типизации в динамическом языке, который я использую в своих проектах. Может мы об одном и том же говорим? Просто вы так делаете на статическом, а я на динамическом. Быть может, не так на самом деле важна типизация под капотом, раз мы с вами делаем это одинаково?
Ну тут я уже отвечал, но вы мне не поверили. Вы убеждены, что нет задач, которые бы в динамике решались проще и быстрее, доказать на кошках я это не смогу, поэтому не могу дальше спорить.
Кстати, про производительность согласен. Но это отдельный разговор.
На это я тут уже отвечал несколько раз. Опять таки, если вы не верите в предыдущий мой ответ, на это тоже я не могу отвечать.
А вот тут до меня дошло, в чем я не прав, спасибо. Я не упомянул, что говорю о статических ООП языках типа явы или шарпа. Мне то не хватало в них чтобы без лишних усилий можно было на лету менять свойства, методы, инжектить свой код в неприличные места в экстренных ситуациях. Но вы же в хаскель практикуете, а я признаться, не знаю, зачем в ФП языках может понадобиться динамическая типизация.
Возможно вы веткой ошиблись. Изначально в своем первом коментарии я поднял тему комбо-типизации, чтобы как раз не спорить, что лучше, а что хуже, а использовать преимущества обеих.
Это все объясняет. И многие предыдущие вопросы тоже. Вам важно, что происходит в компиляторе, мне — нет.
Я бы тоже мог попросить у вас примеров таких задач, с которыми не справляется MyPy, а потом решить ее на простых и читаемых типах. Но мы так просто будем бесконечно по очереди углубляться в примеры.
В динамической типизации для быстрого и эффективного решения или отладки я могу вешать в любых местах архитектуры хуки, делать абсолютно прозрачные подмены чего угодно на лету. Если такое реализовано в каких-то гибких статических языках, то явно этот язык уже не такой уж статический (снаружи), и мне вполне подходит.
В любом случае, я тоже могу ошибаться. Языков так много, и возможно мы просто сравниваем неудачные и удачные случаи на неудачных и удачных языках в неудачных или удачных проектах.
Но я убежден, что гибкие высокоуровневые языки в современном мире должны предоставлять возможность указывать тип и возможность творить магию, динамический ли это язык, или статический.
Неподконтрольная среда — это чужая либа или внешнее API, в котором вы не можете наверняка узнать тип. Да, эта среда нетипизированная.
Я выше описал подробнее, что я имел ввиду.
Только не надо говорить, что проще взять сразу статический язык, я на это уже тут несколько раз отвечал.
Конечно, ведь не существует в мире крутых качественных проектов, где под капотом динамика. Ровно как и не существует плохих глючных проектов, написанных на статике. Практика бывает разная, и каждый оценивает через призму своего опыта. У вас такой опыт и такая статистика. Я же просто призываю людей быть объективными и выключить фанатизм.
Мне второй раз написать, зачем?
И в этом виновата конечно же динамическая типизация? Вы же понимаете, что в случае со статической типизацией, к каждому программисту приставлен человек с пушкой, который следит, чтобы тот везде расставил типы. Если к динамическим программистам приставить такого же наблюдателя, они бы тоже расставили везде типы. То есть ваш тезис в том, что все дело в необходимости контроля ленивых программистов, да?
Это проблема не динамической типизации, а дисциплины. Динамическая типизация позволяет хулиганить, статическая — нет. И из этого нельзя делать ложные выводы, что ВСЕ динамические программисты хулиганы, а ВСЕ статические программисты — молодцы. С таким же успехом можно задвинуть глупый вывод, что статические программисты без ошибок на этапе компиляции тоже бы хулиганили, забивая на типы. Но это неправда, и мы таких глупых выводов делать не станем. Давайте не будем делить мир на черное и белое и соскакивать на другие темы.
Это у вас путаница между тем, что что важно компилятору, и тем, что важно программисту. Мы тут рассматриваем то, с чем приходится работать лично мне, а не компилятору. А мне приходится работать с кодом. Статический это код под капотом или динамический, мне по барабану, если он позволяет в одних местах делать все строго и статично, а в других свободно и динамично.
Чтобы вы перестали скатываться в другие темы, я еще раз хочу напомнить, что говорю я не про конкретные реализации чего-либо, а про саму идею опциональной типизации с точки зрения взгляда программиста. Вам сама идея не нравится? Или в чем вы меня пытаетесь убедить?
Мне по наследству достался прекрасный проект, обильно обмазанный динамичностью и полным отсутствием типов. Вплоть до того, что объекты одного семейства имели разные наборы методов. Сейчас я все это рефакторю, знаете какой это ад? Я чувствую себя настоящим героем. Но почему-то вы не можете поверить, что по мере рефакторинга код становится читаемым, в среде появляются подсказочки, а в рантайме перестают вываливаться ошибки, что метод отсутствует или переменная не определена.
Еще раз повторю (я уже устал, правда): просто взяв статический язык, вы полностью лишаете себя динамичности (об этом ниже), которая иногда очень выручает. Иногда нам нужно сначала быстро решить проблему, а уже потом решить хорошо, это реальность. Так вот динамичность позволяет творить невероятную магию.
В статической типизации вы либо лишаете себя этой магии, либо язык пытается ее каким-то образом реализовать, отвечая на запрос сообщества. А раз он пытается реализовать динамичность, то «можно было бы тогда взять просто динамический язык» (с)
Я не против статичности или динамичности, я против фанатизма.
Зачем везде, если у вас аннотации?
Что есть актикс? Ничего не понял. Не могу ответить.
Ну а дальше по вашему тексту, я думаю мы спорим ни о чем. Вы доказываете, что зебра черная в белую полоску красивее, чем белая в черную полоску. Вы меня ни в чем не убедили, я и так всегда считал важным наличие типизации, просто раньше когда я писал на статических языках, возможно типы нужно было указывать везде. Теперь я знаю, что в статических языках стало попроще с типами. Но так же я знаю, что и в динамических стало получше с аннотациями.
Благодаря этому, роль статической типизации размывается, и мы можем позволить себе выбирать язык по другим факторам, расширяя круг поиска.
2. Выигрыш был описан ниже сразу после этих слов.
И линтеры динамических языков часто сами могут вывести типы в локальных участках. Только причем тут это? Мы не о линтерах, а об идее рассуждаем.
Я сторонник идеи что аннотации превращают динамический язык в статический в нужных местах и не превращают в ненужных. Если вы противопоставляете этой идее свою идею, что в статическом языке тоже можно скрыть типы в локальных участках, то я совершенно не против такого механизма. Я думаю, он хорош.
Если есть статический язык, в котором статичность везде опциональна, а не только в локальном контексте, я только за, потому что хотелось бы самому решать.
Нет, не приходится. Уже давно есть аннотации, которые решают вашу проблему на этапе написания, а не рантайма.
Таким образом достигается комбо преимуществ статической и динамической типизаций. Аннотациями можно полностью покрывать швы. А в локальных участках, где срок жизни какой-то переменной составляет 5 строчек, типизация почти никогда не требуется, особенно, если использовать правильные названия идентификаторов типа attempts_count (попробуете угадать тип?). И даже если по имени тип непонятен, просто поднимите взгляд на пару сантиметров вверх (это на крайний случай). А уж если вы хотите попыткам добавить разных таймаутов, то попробуйте вот это переписать на сишарп (вы же на нем пишете?):
Казалось бы, это все мелочи, но их такое огромное количество, что из них состоит половина кода, что мы пишем.
Кроме того, в такой комбо-типизации значительно упрощается прототипирование. Я могу хоть 10 раз переписать какой-то новый для меня механизм в ходе изучения, а уже готовому варианту расставить типы.
Сам я начинал со статической, и потом несколько раз пытался на нее вернуться, потому что мне реально ее не хватало. Но аннотации меня спасли, и мне стало даже лучше.
И прежде, чем со мной спорить, попробуйте меня понять, вы же видите, что я не фанатик, и не делю мир на черное и белое.
Речь о том, что тот же zip или slice можно использовать не только в циклах. Так зачем запоминать семантику двух разных подходов (for и foreach), когда и циклы, и остальное, можно положить поверх одного for, применяя вспомогательные простые универсальные механизмы, которые касаются не только циклов?
Это проблемы не в динамической типизации, а в сложных структурах и сигнатурах методов. Покажите пример таких структур, которые элегантно описываются в статической типизации, и невозможно было бы описать хинтингом (и как часто у вас такая ситуация возникает?).
Так можно было сказать о самых первых примитивных версиях питона. Сейчас же он слишком далеко ушел, чтобы даже упоминать о шелл скриптах.
Смотрите, я тоже могу цифры выдумывать.
На динамической типизации я могу использовать хинтинг там, где требуется, и не использовать там, где не требуется (например в локальных переменных метода или в каком-нибудь JSON-ответе с сотней полей от кривого стороннего API, из которого мне нужно только одно поле, мне вообще не нужна типизация). Хинтинг решит, описанные вами проблемы и избавит меня от бойлерплейта. При этом упрощается любая динамическая магия и метакод.
Короче в чистом виде и динамическая, и статическая типизация — это для меня неудобно. В идеале, я хочу, чтоб у меня был выбор.