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