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