Книг было довольно много. Была ещё в девяностых серия книг про архитектурные паттерны, паттерны параллельного и распределённого программирования и прочее. Это паттерны на других уровнях абсиракции, и архитектору без этого, спору нет, никак.
Просто, условно, алгебра не отменяет арифметики. Паттерны GoF — это идеи уровня кода и организации групп масштаба нескольких классов. Под ними — кодировочные, над ними — уровня архитектуры. А есть ещё паттерны, применяемые в специфических областях, а не общего назначения.
И всё равно мышление разработчика развивается от простого. Сейчас большинство этих паттернов у почти любого квалифицированного разработчика давно на уровне неосознанной компетентности. Но оно не сразу туда попадает. Нет смысла считать ерундой то, что является для тебя пройденным этапом. Я тоже плотно изучал это в 90-х. Это было полезно, хотя, естественно, это не было последней прочитанной мною книжкой и венцом профессионального развития. :-)
Ну, вообще они от свичей уходили. Для сложной стейк-машины это очень много ошибок даёт. На трёх состояниях, конечно, и так можно. Если честно, в Питоне нет нужды создавать объекты, если от стейта нужен только handle, а не целое семейство методов. Функции на состояние совершенно достаточно. А в сочетании с генератором или async можно реализовать весьма сложную логику внутренних стейтов и иначе — это если у вас, как часто рисуют на диаграммах UML, внутри состояния есть своя машина.
Кстати, стейт в лексерах lex/yacc делается в одном объекте, но разными наборами методов.
Ну, так у меня оно и так ест не так много. Black же вообще даже не в пайплайне сборки, это один запуск перед коммитом. Если б они делали что-то другое... А так-то зачем?
Я пока не пробовал. Как в своё время стал юзать mypy, так поныне и юзаю. Если услышу, что что-то сильно лучше появилось, попробую, но пока только знаю, что есть несколько других чекеров — и всё.
В шаблоне проекта у меня mypy, flake8 как линтер, наконец black для форматирования.
Лишний раз экспериментировать с инфраструктурой, если нет наводки, что что-то уж очень хорошо, мне лень.
Вот мой примерный шаблон проекта для генерации исполняемого модуля через PyInstaller, там много старья типа запускалки тестов, написанной почти 20 лет тому. Но работает, а работает — не трогай:
Кстати, отличная идея. У меня mypy во всех актуальных проектах встроен в сборочные пайплайны, так что для меня она и не стоит почти ничего.
Есть, конечно, возможность преобразовать тип, но это уже будет не глупость по недомыслию, а ярко выраженное вредительство, от такого защититься сложно. :-)
Ну-ну. Куча кода работает вообще в одном процессе. Что-то масштабируется горизонтально, но там синглетон и нужен в каждом процессе.
И я сожалею, что, видимо, пройдя третий класс школы, вы не понимаете различия между многопоточностью, многопроцессностью и распределёнными вычислениями.
Вы вообще о чём? Какие ноды, какой кластер? Синглетон в одном процессе, и это не имеет никакого отношения к распределённым вычислениям вообще. Как и все паттерны GoF, кстати.
P. S. Распределёнными системами я занимался, но тут-то это при чём?
И да, создавать эти проблемы чаще всего не нужно. Но иногда они возникают, что бывает довольно неприятно, особенно если в голове нет наработанных решений для всего этого. Паттерны, реализация паттернов — для этого. Прикладная разработка — про решение ровно своих задач, используя ту поваренную книгу, которая наработана в голове. И там далеко не только GoF, одного GoF очень мало. Там все наши кодировочные идиомы. Ты масса архитектурных решений, которые мы видели в своей биографии, осмыслили — и стали применять на свой манер. Разноуровневых паттернов много. Иногда мы расширяем эту поваренную книгу, когда решаем что-то новое.
Вот буквально на днях я писал парсер языка на PLY. И понял, что мне нельзя запихать в yacc полную грамматику: сообщения об ошибках становятся невразумительными. И я стал парсить код как набор операторов, который иерархически организован в блоки. Каждый оператор парсится, структура блоков тоже. Собираю AST, даже если сочетания операторов бредовые и бессмысленные. А сгенерировал AST — пошёл по нему визиторами и там ВРУЧНУЮ проверил осмысленность сочетаний, выдавая осмысленные ошибки, а не «Syntax error near token '\n'» на десять строк выше места проблемы, поскольку правило не матчится именно оттуда. Если в терминах C, то сгенерированный парсер пропустит такой бред: i = i+1; {main() {return 0;}}. Паттерн можно назвать «Ограничение сферы ответственности сгенерированных парсеров». Позволяет анализировать структуру даже не вполне корректного кода. Он теперь есть в голове, в следующий раз уже знаю, что делать. не вполне корректного кода, даёт осмысленные сообщения об ошибках. Есть сфера применения, есть решение. Язык реализации и средство автогенерации парсеров по грамматике значения не имеют. Вполне личный паттерн. Правда, уже узнал, что так иногда и другие делают. Значит, вообще нормальный паттерн. Для тех, кто пишет парсеры. Будет в моей кулинарной книге и дальше.
И, кстати, эта конкретная статья ровно про предостережение, чего делать НЕ НАДО. Я намеренно собрал рекомендации, которые считаю — в основном — идиотскими (Но они очень стойкие. Каждый второй лепит подобное на каком-то этапе. Спросишь ChatGPT — обязательно посоветует их.) С объяснением, что все эти реализованные руками потокобезопасности и прочее не так универсальны, и если уж язык предоставляет готовое подходящее средство, использовать надо именно его, а не DCL и прочую хрень.
Да, случаев, когда он нужен, немного. Settings — действительн сами по себе синглетон. И да, инициализация в модуле и соглашения. В случае с settings я часто использую соглашение, что все донастройки settings — в главном модуле, в функции main и только до начала инициализации содержательной части системы (ну или в главной запускалке тестов — тоже до какой-то содержательной активности). Больше никто этого делать не должен. С чем стартовали, с тем живём. Ну, скажем, после разбора параметров командной строки и просмотра окружения выставил я язык локализации — и начал поднимать компоненты. И всё, дальше туда не лезть, только читать.
Можно, конечно, запретить запись в settings централизованно. ))) Но одно дело — в сами поля settings, а вот каждый элемент каждого словаря или списка замучишься защищать. Так что, если в проекте нет толпы джуниоров, можно не париться.
Я тоже смотрю чуть с другого. В спецификацию языка включили не паттерны, а средства их реализации. Скажем, асинхронное выполнение кода — тоже вполне себе паттерн. Очень долго всё было на колбэках. А потом в языки один за другим стали пролезать способы писать этот код совсем иначе, даже до C++ уже доехало. Были паттерны (повыше уровнем, чем GoF, всякие реакторы и проакторы) — появилось средство их удобной реализации.
Чё, подгорает, зелёненький мой?
Do not feed the troll
flake8
И оно, конечно, в пайплайне на PR
Black — локально. А пайплайн сборки (включая PR) на GitHub Actions. Естественно, линтер и контроль типов в него включены.
То есть форматирование своих изменений каждый делает сам. Не отформатированное просто не принимается.
Книг было довольно много. Была ещё в девяностых серия книг про архитектурные паттерны, паттерны параллельного и распределённого программирования и прочее. Это паттерны на других уровнях абсиракции, и архитектору без этого, спору нет, никак.
Просто, условно, алгебра не отменяет арифметики. Паттерны GoF — это идеи уровня кода и организации групп масштаба нескольких классов. Под ними — кодировочные, над ними — уровня архитектуры. А есть ещё паттерны, применяемые в специфических областях, а не общего назначения.
И всё равно мышление разработчика развивается от простого. Сейчас большинство этих паттернов у почти любого квалифицированного разработчика давно на уровне неосознанной компетентности. Но оно не сразу туда попадает. Нет смысла считать ерундой то, что является для тебя пройденным этапом. Я тоже плотно изучал это в 90-х. Это было полезно, хотя, естественно, это не было последней прочитанной мною книжкой и венцом профессионального развития. :-)
Ну, вообще они от свичей уходили. Для сложной стейк-машины это очень много ошибок даёт. На трёх состояниях, конечно, и так можно. Если честно, в Питоне нет нужды создавать объекты, если от стейта нужен только handle, а не целое семейство методов. Функции на состояние совершенно достаточно. А в сочетании с генератором или async можно реализовать весьма сложную логику внутренних стейтов и иначе — это если у вас, как часто рисуют на диаграммах UML, внутри состояния есть своя машина.
Кстати, стейт в лексерах lex/yacc делается в одном объекте, но разными наборами методов.
Ну, так у меня оно и так ест не так много. Black же вообще даже не в пайплайне сборки, это один запуск перед коммитом. Если б они делали что-то другое... А так-то зачем?
Я пока не пробовал. Как в своё время стал юзать mypy, так поныне и юзаю. Если услышу, что что-то сильно лучше появилось, попробую, но пока только знаю, что есть несколько других чекеров — и всё.
В шаблоне проекта у меня mypy, flake8 как линтер, наконец black для форматирования.
Лишний раз экспериментировать с инфраструктурой, если нет наводки, что что-то уж очень хорошо, мне лень.
Вот мой примерный шаблон проекта для генерации исполняемого модуля через PyInstaller, там много старья типа запускалки тестов, написанной почти 20 лет тому. Но работает, а работает — не трогай:
https://github.com/twinpigs-agile/python-prj-template
Я вас уже простил, вечная вам память.
Кстати, отличная идея. У меня mypy во всех актуальных проектах встроен в сборочные пайплайны, так что для меня она и не стоит почти ничего.
Есть, конечно, возможность преобразовать тип, но это уже будет не глупость по недомыслию, а ярко выраженное вредительство, от такого защититься сложно. :-)
Ваш тоже. Это называется самоутверждающийся демагог-поливатель. Удачи вам в нелёгком деле. Прощаю, так и быть.
Ну-ну. Куча кода работает вообще в одном процессе. Что-то масштабируется горизонтально, но там синглетон и нужен в каждом процессе.
И я сожалею, что, видимо, пройдя третий класс школы, вы не понимаете различия между многопоточностью, многопроцессностью и распределёнными вычислениями.
Вы вообще о чём? Какие ноды, какой кластер? Синглетон в одном процессе, и это не имеет никакого отношения к распределённым вычислениям вообще. Как и все паттерны GoF, кстати.
P. S. Распределёнными системами я занимался, но тут-то это при чём?
И да, создавать эти проблемы чаще всего не нужно. Но иногда они возникают, что бывает довольно неприятно, особенно если в голове нет наработанных решений для всего этого. Паттерны, реализация паттернов — для этого. Прикладная разработка — про решение ровно своих задач, используя ту поваренную книгу, которая наработана в голове. И там далеко не только GoF, одного GoF очень мало. Там все наши кодировочные идиомы. Ты масса архитектурных решений, которые мы видели в своей биографии, осмыслили — и стали применять на свой манер. Разноуровневых паттернов много. Иногда мы расширяем эту поваренную книгу, когда решаем что-то новое.
Вот буквально на днях я писал парсер языка на PLY. И понял, что мне нельзя запихать в yacc полную грамматику: сообщения об ошибках становятся невразумительными. И я стал парсить код как набор операторов, который иерархически организован в блоки. Каждый оператор парсится, структура блоков тоже. Собираю AST, даже если сочетания операторов бредовые и бессмысленные. А сгенерировал AST — пошёл по нему визиторами и там ВРУЧНУЮ проверил осмысленность сочетаний, выдавая осмысленные ошибки, а не «Syntax error near token '\n'» на десять строк выше места проблемы, поскольку правило не матчится именно оттуда. Если в терминах C, то сгенерированный парсер пропустит такой бред: i = i+1; {main() {return 0;}}. Паттерн можно назвать «Ограничение сферы ответственности сгенерированных парсеров». Позволяет анализировать структуру даже не вполне корректного кода. Он теперь есть в голове, в следующий раз уже знаю, что делать. не вполне корректного кода, даёт осмысленные сообщения об ошибках. Есть сфера применения, есть решение. Язык реализации и средство автогенерации парсеров по грамматике значения не имеют. Вполне личный паттерн. Правда, уже узнал, что так иногда и другие делают. Значит, вообще нормальный паттерн. Для тех, кто пишет парсеры. Будет в моей кулинарной книге и дальше.
И, кстати, эта конкретная статья ровно про предостережение, чего делать НЕ НАДО. Я намеренно собрал рекомендации, которые считаю — в основном — идиотскими (Но они очень стойкие. Каждый второй лепит подобное на каком-то этапе. Спросишь ChatGPT — обязательно посоветует их.) С объяснением, что все эти реализованные руками потокобезопасности и прочее не так универсальны, и если уж язык предоставляет готовое подходящее средство, использовать надо именно его, а не DCL и прочую хрень.
Да, случаев, когда он нужен, немного. Settings — действительн сами по себе синглетон. И да, инициализация в модуле и соглашения. В случае с settings я часто использую соглашение, что все донастройки settings — в главном модуле, в функции main и только до начала инициализации содержательной части системы (ну или в главной запускалке тестов — тоже до какой-то содержательной активности). Больше никто этого делать не должен. С чем стартовали, с тем живём. Ну, скажем, после разбора параметров командной строки и просмотра окружения выставил я язык локализации — и начал поднимать компоненты. И всё, дальше туда не лезть, только читать.
Можно, конечно, запретить запись в settings централизованно. ))) Но одно дело — в сами поля settings, а вот каждый элемент каждого словаря или списка замучишься защищать. Так что, если в проекте нет толпы джуниоров, можно не париться.
Я тоже смотрю чуть с другого. В спецификацию языка включили не паттерны, а средства их реализации. Скажем, асинхронное выполнение кода — тоже вполне себе паттерн. Очень долго всё было на колбэках. А потом в языки один за другим стали пролезать способы писать этот код совсем иначе, даже до C++ уже доехало. Были паттерны (повыше уровнем, чем GoF, всякие реакторы и проакторы) — появилось средство их удобной реализации.
Именно! Потому я и говорю, что паттерны актуальны. Паттерны — это в первую очередь "что и зачем". А реализация — это про "как".
Но тоже надо постараться. Редактировать sys.path между загрузками, скажем.
Но я всё равно бы скорее стал работать с классом без экземпляра. Впрочем, это тоже рабочий способ.
Тоже, кстати, вариант.