Сам, от части, являюсь таким же и мне кажется, что вы правы на счёт увлечённости.
Разработчики занимаются решением проблем. Путь к росту лежит через самостоятельное решение проблем. Думалка на этом пути у большинства людей весьма ограничена. Когда мы сталкиваемся с сложными задачами в условиях дедлайна - не всегда есть возможность вникнуть на достаточно глубоком уровне, но, к сожалению, такое оправдание очень легко входит в привычку:
Закралось подозрение в повторении участка кода - не проверил, возможно, отложив на попозже.
Не обдумал возможные дальнейшие шаги после реализации решения и просто сделал, что требуется сейчас.
Дописал фитчу и быстро закрыл задачу вместо ещё одного взгляда. Возможно где-то нужна декомпозиция?
Таких примеров можно придумать множество...
Если смотреть под таким углом, то все это выглядит, как лень и попытка оправдать себя. Единственный способ расти в такой ситуации - это действительно тяжёлая работа, в первую очередь, над самим собой.
Без увлечённости, сформировать новые привычки или изменить старые - будет на несколько порядков сложнее.
Poetry не является, как основополагающим, так и безальтернативным инструментом. Никто не запретит в случае изменения политики пересобрать pyproject на проекте и заменить 2 строчки в Dockerfile в тот момент, когда это будет необходимо. Такие опасения в данный момент, не кажутся существенными, если как альтернативу рассматривать именно pip.
Pip все так же не умеет решать конфликты зависимостей, а для большинства - это практически единственная важная фитча поэзии. resolver - это шаг вперёд, но всё ещё не решение проблемы.
Если речь идёт именно о приложениях, чаще всего, подразумевается, что они должны работать в пачке. В таком случае самым простым и удобным, лично для себя, нашел перегрузку конфигураций для docker-compose и использование debugpy для отладки (dev-dependecies poetry). В pycharm или vsc - достаточно просто оставить дебаггеру открытый порт.
Проще и надёжнее отлаживать код в той среде, в которой он должен будет работать)
Редактировать каталоги онлайн-библиотеки? Не очень большая ниша, но всё же, хорошо каталогизированная онлайн-библиотека с правильно расставленными тегами и, возможно, где-то дополненная правильными связями вручную, дополнительно к современным методам - дорогого стоит. В первую очередь библиотекарь, как мне кажется - эксперт в области сортировки и каталогизации книг.
В данный момент в Pyhton такая конструкция используется для аннотации типов возвращаемого значения. Подробнее можно познакомиться тут.
А вот эти двойные подчёркивания в функциях нахрена?
Решение спорное, но вполне решает поставленную задачу: сделать так, чтобы никто не назвал свой метод new() перезаписав важный "магический метод". Как я понял, кроме статичности классов принципы работы не изменились. Подробнее про "магические методы" тут.
Мне кажется еще довольно интересно: - сокрытие на уровне класса, модуля. Как мы знаем, в Python с этим есть некоторые узкие моменты... - если обычный класс сделали статичным, как поступили с метаклассами?
Раз метрикам верить нельзя, то как тогда оценить, какой кодек из уже имеющихся или скоро возникнувших наиболее хорош по соотношению уровень_сжатия/качество?
Как не совсем знакомый с кухней человек могу предположить, что проблему можно решить случайным лесом с несколькими метриками и хитрой нейронкой, определяющей шум с нескольких кадров для подтверждения вмешательства с целью накрутки метрики.
Добавлю, что есть еще направления в которых действует конкурентная система для команд вынужденных кооперировать и "соревноваться". Даже описать словами сложно что происходит, когда цель "получить баллы" и "забраться повыше" практически полностью вытесняет цель "принести прибыль". В ход идут все возможные средства...
Мне кажется, что истина в разумном комбинировании этих способов. По большей части, подробное описание позволяет подготовиться к тому, что ты увидишь дальше, но в условном getter методе, как мне кажется, подобное может быть избыточным.
Наблюдал еще более интересный кейс: При существующей и вполне функциональной ERP внедряется решение 1С и обе системы живут параллельно (одни и те же работники вносят одни и те же данные в обе системы).
К концу отчетного периода вытягивают отчеты из обеих систем, после чего прорабатывают diff-ы.
Сам, от части, являюсь таким же и мне кажется, что вы правы на счёт увлечённости.
Разработчики занимаются решением проблем. Путь к росту лежит через самостоятельное решение проблем. Думалка на этом пути у большинства людей весьма ограничена. Когда мы сталкиваемся с сложными задачами в условиях дедлайна - не всегда есть возможность вникнуть на достаточно глубоком уровне, но, к сожалению, такое оправдание очень легко входит в привычку:
Закралось подозрение в повторении участка кода - не проверил, возможно, отложив на попозже.
Не обдумал возможные дальнейшие шаги после реализации решения и просто сделал, что требуется сейчас.
Дописал фитчу и быстро закрыл задачу вместо ещё одного взгляда. Возможно где-то нужна декомпозиция?
Таких примеров можно придумать множество...
Если смотреть под таким углом, то все это выглядит, как лень и попытка оправдать себя. Единственный способ расти в такой ситуации - это действительно тяжёлая работа, в первую очередь, над самим собой.
Без увлечённости, сформировать новые привычки или изменить старые - будет на несколько порядков сложнее.
Синей или красной :)
Poetry не является, как основополагающим, так и безальтернативным инструментом. Никто не запретит в случае изменения политики пересобрать pyproject на проекте и заменить 2 строчки в Dockerfile в тот момент, когда это будет необходимо. Такие опасения в данный момент, не кажутся существенными, если как альтернативу рассматривать именно pip.
Pip все так же не умеет решать конфликты зависимостей, а для большинства - это практически единственная важная фитча поэзии. resolver - это шаг вперёд, но всё ещё не решение проблемы.
Если речь идёт именно о приложениях, чаще всего, подразумевается, что они должны работать в пачке. В таком случае самым простым и удобным, лично для себя, нашел перегрузку конфигураций для docker-compose и использование debugpy для отладки (dev-dependecies poetry). В pycharm или vsc - достаточно просто оставить дебаггеру открытый порт.
Проще и надёжнее отлаживать код в той среде, в которой он должен будет работать)
Редактировать каталоги онлайн-библиотеки?
Не очень большая ниша, но всё же, хорошо каталогизированная онлайн-библиотека с правильно расставленными тегами и, возможно, где-то дополненная правильными связями вручную, дополнительно к современным методам - дорогого стоит. В первую очередь библиотекарь, как мне кажется - эксперт в области сортировки и каталогизации книг.
В данный момент в Pyhton такая конструкция используется для аннотации типов возвращаемого значения. Подробнее можно познакомиться тут.
Решение спорное, но вполне решает поставленную задачу: сделать так, чтобы никто не назвал свой метод new() перезаписав важный "магический метод". Как я понял, кроме статичности классов принципы работы не изменились. Подробнее про "магические методы" тут.
Мне кажется еще довольно интересно:
- сокрытие на уровне класса, модуля. Как мы знаем, в Python с этим есть некоторые узкие моменты...
- если обычный класс сделали статичным, как поступили с метаклассами?
Как не совсем знакомый с кухней человек могу предположить, что проблему можно решить случайным лесом с несколькими метриками и хитрой нейронкой, определяющей шум с нескольких кадров для подтверждения вмешательства с целью накрутки метрики.
Добавлю, что есть еще направления в которых действует конкурентная система для команд вынужденных кооперировать и "соревноваться". Даже описать словами сложно что происходит, когда цель "получить баллы" и "забраться повыше" практически полностью вытесняет цель "принести прибыль". В ход идут все возможные средства...
Мне кажется, что истина в разумном комбинировании этих способов. По большей части, подробное описание позволяет подготовиться к тому, что ты увидишь дальше, но в условном getter методе, как мне кажется, подобное может быть избыточным.
Наблюдал еще более интересный кейс:
При существующей и вполне функциональной ERP внедряется решение 1С и обе системы живут параллельно (одни и те же работники вносят одни и те же данные в обе системы).
К концу отчетного периода вытягивают отчеты из обеих систем, после чего прорабатывают diff-ы.