А в чём именно вы видите кривой дизайн? В том, что в питоне нельзя по ошибке применить конкатенацию вместо сложения?
>> пытаются вылечить головную боль методом внедрения гильотин
А вот здесь вообще о чем речь? Ещё раз повторюсь - в питоне вообще нет никакой путаницы сложения и конкатенации. Поэтому в питоне никто не пытается решить эту проблему, за отсутствием проблемы. Аннотации используются вообще для другого.
>> И я говорю о проблеме в целом (об исследовании Ларри), а не о Python конкретно.
О какой проблеме-то? Во многих языках (включая питон) нет проблемы с неоднозначностью сложения/конкатенации, а польза от типов - есть.
И типы, внезапно, нужны не только для того, чтобы сделать счастливым компилятор. А ещё и для того, чтобы сделать работу программиста проще и сократить число ошибок.
И, кстати, почему вы упорно называете Ларри Уолла только по имени? Вы с ним лично знакомы?
Ведь они являются полноценным атрибутом, и программист вполне может завязать какую-то логику на проверку аннотаций функции. Было бы странно, если бы оптимизация ломала такую логику.
В питоне для датаклассов обычно не используются какие-то отдельные функции конструкторы. А само по себе инстанцирование датакласса занимает примерно столько же места, сколько и создание словаря.
Ну, если у вас словарь, то вы, конечно, можете написать аннотацию dict[string, Any], но толку тут не много, вы всё-равно не знаете, какие ключи в этом словаре. А в датаклассе полностью определён перечень полей и типы их значений.
Речь-то в статье вообще про другое. В питоне и так типы есть, сложить строку с числом у вас не получится. Проблема в том, что тип становится известен только в процессе выполнения.
Поддерживать код, у которого не размечены типы - очень-очень больно.
Сейчас я работаю на проекте, где в одном из сервисов есть огромное число функций, которые принимают аргумент opts, или params, или оба этих аргумента одновременно. Эти аргументы являются словарями, которые формируются постепенно - то есть по мере того, как они пробрасываются из функции в функцию, они могут обогащаться новыми ключами.
В итоге глядя только на функцию, вы не можете знать, какие ключи вообще есть в этих словарях, и какой формат могут иметь их значения. Приходится каждый раз долго лазить по всему коду, и всё равно полной уверенности нет.
А если бы в эти аргументы передавались датаклассы, и были бы проставлены соответствующие аннотации, то это полностью избавило бы меня от такой проблемы.
Всё-таки я бы сказал, что стремиться надо к тому, чтобы констрейнты базы данных отвечали только за консистентность данных.
То есть, например, если запись в таблице A ссылается на запись в таблице B, то соответствующая запись в B должна существовать, - это хороший пример использования констрейнта.
Или не должно быть записей с одинаковым ключом, - это тоже хороший пример.
А ограничения бизнес-логики не надо тащить в базу. Поначалу это может выглядеть как хороший способ лишний раз подстелить соломки. А через пару лет выстрелит очень-очень больно.
Если есть необходимость валидировать бизнес-логику, и быть уверенным, что мы эту валидацию всюду делаем одинаково, то в некоторых случаях хорошим решением будет создать апи, которое единственное будет писать в базу. А все остальные части системы будут взаимодействовать с базой только через него.
Так вы можете писать валидацию бизнес-логики на языке, подходящем для написания бизнес-логики, а не через триггеры с констрейнтами.
Потому, что философия — это искусство сомневаться. А вовсе не то, что писали аристотель с платоном
Я прямо по этому утверждению вижу, что в первую очередь философия — это выдумывание удобных определений на ходу, подмена понятий и прочее словоблудие.
Вот именно за это её и не любят. За то, что в философии можно из воздуха выхватить абсолютно любой удобный тезис, не заботясь о том, чем он обоснован. Потому что обоснование всегда можно придумать уже задним числом.
Философия всегда готова приписать себе всё хорошее, что есть в науке, этике и здравом смысле. Но если начать говорить о конкретике, если спросить у вас хоть какую-то ясную методологию получения тех сокровищ мудрости, на которые философия якобы так горазда, то в ответ — невнятное блеяние и общие слова.
Ну и конечно, как же в дискуссии о философии обойтись без аргумента "ненастоящего шотландца". Если что-то в философии явно показало свою ущербность — то это "ненастоящая философия". Но критериев как отличить "настоящую" философию от "ненастоящей" нету. Это всегда объеснение задним числом.
И как бы философия тут помогла?
Только без общих слов про то, что философия является базой в вопросах этики.
Как раз-таки привычка предаваться философии делает человека уязвимым к манипуляциям через такие пропагандистские концепции как "историческая справедливость", "национальное самосознание", "национальная идея" и т.п.
Здоровому человеку не нужна философия, чтобы понимать, что война — плохо.
Как вы сформулируете эти "общие вопросы", не занимаясь предварительно частностями?
В реальности контуры общих вопросов можно наметить только после того, как произведена какая-то работа на массиве частных вопросов.
Без этого попытка выглючить общие вопросы из головы порождает только пустые химеры.
В античности и средние века под философией понимали вообще всё, что не являлось прикладным знанием.
После того, как оформился научный подход, всё ценное выделилось из философии в отдельные научные направления — логику, психологию, естественные науки, методологию и тд, и тп. Осталась только всякая ментальная шелуха, не обладающая никакой ценностью.
И говорить, что этот шлак обладает ценность, потому что "все другие науки произошли от него", это всё равно, что превозносить алхимию. То есть да, алхимики сделали много открытий и разработали много методик работы с веществом. Но после появления полноценной химической науки алхимию можно сдавать в утиль.
Мне в этом плане нравится утверждение, что в питоне фактически присутствует то, что можно назвать Gradual Typing (постепенная типизация).
То есть простой и очевидный код или прототип мы можем писать и менять очень быстро без заморочек с типами. А когда код стабилизируется и начинает обрастать логикой, мы можем постепенно вводить типы, основываясь на уже настоявшихся абстракциях.
Это даёт гибкость, но действительно требует определённой культуры разработки, которая не у всех есть.
Впрочем, в последние годы всё больше вижу, что народ распробовал аннотирование типов.
>> То, что Python криво задизайнили
А в чём именно вы видите кривой дизайн? В том, что в питоне нельзя по ошибке применить конкатенацию вместо сложения?
>> пытаются вылечить головную боль методом внедрения гильотин
А вот здесь вообще о чем речь? Ещё раз повторюсь - в питоне вообще нет никакой путаницы сложения и конкатенации. Поэтому в питоне никто не пытается решить эту проблему, за отсутствием проблемы. Аннотации используются вообще для другого.
>> И я говорю о проблеме в целом (об исследовании Ларри), а не о Python конкретно.
О какой проблеме-то? Во многих языках (включая питон) нет проблемы с неоднозначностью сложения/конкатенации, а польза от типов - есть.
И типы, внезапно, нужны не только для того, чтобы сделать счастливым компилятор. А ещё и для того, чтобы сделать работу программиста проще и сократить число ошибок.
И, кстати, почему вы упорно называете Ларри Уолла только по имени? Вы с ним лично знакомы?
В питоне под аннотациями понимают вполне конкретную вещь. В статье речь именно про питоновские аннотации.
Ну, логично, что аннотации не вырезаются.
Ведь они являются полноценным атрибутом, и программист вполне может завязать какую-то логику на проверку аннотаций функции. Было бы странно, если бы оптимизация ломала такую логику.
>> а сконкатенировать?
А что вы вообще подразумеваете под конкатенацией строки и числа применительно к питону? И чем это отличается от сложения строки и числа?
В питоне для датаклассов обычно не используются какие-то отдельные функции конструкторы. А само по себе инстанцирование датакласса занимает примерно столько же места, сколько и создание словаря.
>> разве аннотаций недостаточно?
Ну, если у вас словарь, то вы, конечно, можете написать аннотацию dict[string, Any], но толку тут не много, вы всё-равно не знаете, какие ключи в этом словаре. А в датаклассе полностью определён перечень полей и типы их значений.
Речь-то в статье вообще про другое. В питоне и так типы есть, сложить строку с числом у вас не получится. Проблема в том, что тип становится известен только в процессе выполнения.
Поддерживать код, у которого не размечены типы - очень-очень больно.
Сейчас я работаю на проекте, где в одном из сервисов есть огромное число функций, которые принимают аргумент opts, или params, или оба этих аргумента одновременно. Эти аргументы являются словарями, которые формируются постепенно - то есть по мере того, как они пробрасываются из функции в функцию, они могут обогащаться новыми ключами.
В итоге глядя только на функцию, вы не можете знать, какие ключи вообще есть в этих словарях, и какой формат могут иметь их значения. Приходится каждый раз долго лазить по всему коду, и всё равно полной уверенности нет.
А если бы в эти аргументы передавались датаклассы, и были бы проставлены соответствующие аннотации, то это полностью избавило бы меня от такой проблемы.
Всё-таки я бы сказал, что стремиться надо к тому, чтобы констрейнты базы данных отвечали только за консистентность данных.
То есть, например, если запись в таблице A ссылается на запись в таблице B, то соответствующая запись в B должна существовать, - это хороший пример использования констрейнта.
Или не должно быть записей с одинаковым ключом, - это тоже хороший пример.
А ограничения бизнес-логики не надо тащить в базу. Поначалу это может выглядеть как хороший способ лишний раз подстелить соломки. А через пару лет выстрелит очень-очень больно.
Если есть необходимость валидировать бизнес-логику, и быть уверенным, что мы эту валидацию всюду делаем одинаково, то в некоторых случаях хорошим решением будет создать апи, которое единственное будет писать в базу. А все остальные части системы будут взаимодействовать с базой только через него.
Так вы можете писать валидацию бизнес-логики на языке, подходящем для написания бизнес-логики, а не через триггеры с констрейнтами.
"Трайб" - это вполне устоявшийся термин внутри agile
Инстанс класса возвращает
__new__. А__init__вызывается уже после него.Это какой-то странный юмор, или вы всерьёз?
Вам действительно "питонист" режет ухо, а "питонщик" - не режет?
У меня вопрос — а где, собственно, обещанное в заголовке "глубокое погружение" ?
Я бы написал так:
или так
А бывают какие-нибудь недорогие сплит-клавиатуры для начинающих? Тупо чтобы попробовать и решить — нужно мне это вообще или нет.
Здесь философы просто обязаны сказать, что это от того, что Фейнман просто не понимает всей глубины физики :)
Я прямо по этому утверждению вижу, что в первую очередь философия — это выдумывание удобных определений на ходу, подмена понятий и прочее словоблудие.
Вот именно за это её и не любят. За то, что в философии можно из воздуха выхватить абсолютно любой удобный тезис, не заботясь о том, чем он обоснован. Потому что обоснование всегда можно придумать уже задним числом.
Философия всегда готова приписать себе всё хорошее, что есть в науке, этике и здравом смысле. Но если начать говорить о конкретике, если спросить у вас хоть какую-то ясную методологию получения тех сокровищ мудрости, на которые философия якобы так горазда, то в ответ — невнятное блеяние и общие слова.
Ну и конечно, как же в дискуссии о философии обойтись без аргумента "ненастоящего шотландца". Если что-то в философии явно показало свою ущербность — то это "ненастоящая философия". Но критериев как отличить "настоящую" философию от "ненастоящей" нету. Это всегда объеснение задним числом.
И как бы философия тут помогла?
Только без общих слов про то, что философия является базой в вопросах этики.
Как раз-таки привычка предаваться философии делает человека уязвимым к манипуляциям через такие пропагандистские концепции как "историческая справедливость", "национальное самосознание", "национальная идея" и т.п.
Здоровому человеку не нужна философия, чтобы понимать, что война — плохо.
Как вы сформулируете эти "общие вопросы", не занимаясь предварительно частностями?
В реальности контуры общих вопросов можно наметить только после того, как произведена какая-то работа на массиве частных вопросов.
Без этого попытка выглючить общие вопросы из головы порождает только пустые химеры.
В античности и средние века под философией понимали вообще всё, что не являлось прикладным знанием.
После того, как оформился научный подход, всё ценное выделилось из философии в отдельные научные направления — логику, психологию, естественные науки, методологию и тд, и тп. Осталась только всякая ментальная шелуха, не обладающая никакой ценностью.
И говорить, что этот шлак обладает ценность, потому что "все другие науки произошли от него", это всё равно, что превозносить алхимию. То есть да, алхимики сделали много открытий и разработали много методик работы с веществом. Но после появления полноценной химической науки алхимию можно сдавать в утиль.
Мне в этом плане нравится утверждение, что в питоне фактически присутствует то, что можно назвать Gradual Typing (постепенная типизация).
То есть простой и очевидный код или прототип мы можем писать и менять очень быстро без заморочек с типами. А когда код стабилизируется и начинает обрастать логикой, мы можем постепенно вводить типы, основываясь на уже настоявшихся абстракциях.
Это даёт гибкость, но действительно требует определённой культуры разработки, которая не у всех есть.
Впрочем, в последние годы всё больше вижу, что народ распробовал аннотирование типов.