Pull to refresh
4
0.2
Send message

В Москве - шаурмист, в Питере - шавермейстер.

>> за необоснованный ООП

За необоснованное что угодно можно бить по рукам.

Но при правильном использовании и ООП, и типы, облегчают работу с кодом, а не усложняют. Если у вас типы и ООП только мешают - то либо вы работаете с какими совсем уж специфичными кейсами, либо вы просто не умеете их готовить.

Я не знаю, что у вас за специфичный проект такой был.

В моей практике большинство проектов пишутся за достаточно небольшой период времени, а потом годы занимает их поддержка и доработка. И поэтому основную часть времени разработчик читает код, а не пишет. В таком режиме хорошо расставленные типы могут сократить затраченное разработчиком время в десятки раз. И значительно сократить количество багов при изменении существующего кода.

Ну и расстановка типов не увеличивает как-то драматически ни объём кода, ни затраченное время на его написание.Уж точно не в разы, даже если сказать, что на 10% - то это достаточно пессимистичная оценка.

del, не туда ответил

Вы когда-нибудь занимались поддержкой проекта на 100000+ строк, в который два десятка программистов несколько лет писали?

Я бы посмотрел, как вы это будете без типов делать.

>> в бестиповом языке

Вот только в питоне строгая типизация.

>> То, что Python криво задизайнили

А в чём именно вы видите кривой дизайн? В том, что в питоне нельзя по ошибке применить конкатенацию вместо сложения?

>> пытаются вылечить головную боль методом внедрения гильотин

А вот здесь вообще о чем речь? Ещё раз повторюсь - в питоне вообще нет никакой путаницы сложения и конкатенации. Поэтому в питоне никто не пытается решить эту проблему, за отсутствием проблемы. Аннотации используются вообще для другого.

>> И я говорю о проблеме в целом (об исследовании Ларри), а не о Python конкретно.

О какой проблеме-то? Во многих языках (включая питон) нет проблемы с неоднозначностью сложения/конкатенации, а польза от типов - есть.

И типы, внезапно, нужны не только для того, чтобы сделать счастливым компилятор. А ещё и для того, чтобы сделать работу программиста проще и сократить число ошибок.

И, кстати, почему вы упорно называете Ларри Уолла только по имени? Вы с ним лично знакомы?

В питоне под аннотациями понимают вполне конкретную вещь. В статье речь именно про питоновские аннотации.

Ну, логично, что аннотации не вырезаются.

Ведь они являются полноценным атрибутом, и программист вполне может завязать какую-то логику на проверку аннотаций функции. Было бы странно, если бы оптимизация ломала такую логику.

>> а сконкатенировать?

А что вы вообще подразумеваете под конкатенацией строки и числа применительно к питону? И чем это отличается от сложения строки и числа?

В питоне для датаклассов обычно не используются какие-то отдельные функции конструкторы. А само по себе инстанцирование датакласса занимает примерно столько же места, сколько и создание словаря.

>> разве аннотаций недостаточно?

Ну, если у вас словарь, то вы, конечно, можете написать аннотацию dict[string, Any], но толку тут не много, вы всё-равно не знаете, какие ключи в этом словаре. А в датаклассе полностью определён перечень полей и типы их значений.

Речь-то в статье вообще про другое. В питоне и так типы есть, сложить строку с числом у вас не получится. Проблема в том, что тип становится известен только в процессе выполнения.

Поддерживать код, у которого не размечены типы - очень-очень больно.

Сейчас я работаю на проекте, где в одном из сервисов есть огромное число функций, которые принимают аргумент opts, или params, или оба этих аргумента одновременно. Эти аргументы являются словарями, которые формируются постепенно - то есть по мере того, как они пробрасываются из функции в функцию, они могут обогащаться новыми ключами.

В итоге глядя только на функцию, вы не можете знать, какие ключи вообще есть в этих словарях, и какой формат могут иметь их значения. Приходится каждый раз долго лазить по всему коду, и всё равно полной уверенности нет.

А если бы в эти аргументы передавались датаклассы, и были бы проставлены соответствующие аннотации, то это полностью избавило бы меня от такой проблемы.

Всё-таки я бы сказал, что стремиться надо к тому, чтобы констрейнты базы данных отвечали только за консистентность данных.

То есть, например, если запись в таблице A ссылается на запись в таблице B, то соответствующая запись в B должна существовать, - это хороший пример использования констрейнта.

Или не должно быть записей с одинаковым ключом, - это тоже хороший пример.

А ограничения бизнес-логики не надо тащить в базу. Поначалу это может выглядеть как хороший способ лишний раз подстелить соломки. А через пару лет выстрелит очень-очень больно.

Если есть необходимость валидировать бизнес-логику, и быть уверенным, что мы эту валидацию всюду делаем одинаково, то в некоторых случаях хорошим решением будет создать апи, которое единственное будет писать в базу. А все остальные части системы будут взаимодействовать с базой только через него.

Так вы можете писать валидацию бизнес-логики на языке, подходящем для написания бизнес-логики, а не через триггеры с констрейнтами.

Инстанс класса возвращает __new__. А __init__ вызывается уже после него.

Это какой-то странный юмор, или вы всерьёз?

Вам действительно "питонист" режет ухо, а "питонщик" - не режет?

Если вам понравилась эта статья или у вас есть дополнительные вопросы, пожалуйста, оставьте свой комментарий ниже!

У меня вопрос — а где, собственно, обещанное в заголовке "глубокое погружение" ?

Я бы написал так:


found = any(predicate(x) for x in iterable)
if not found:
  raise NotFoundException()

или так


found = any(map(predicate, iterable))
if not found:
  raise NotFoundException()

А бывают какие-нибудь недорогие сплит-клавиатуры для начинающих? Тупо чтобы попробовать и решить — нужно мне это вообще или нет.

Information

Rating
2,194-th
Registered
Activity