В целом, да, для общего развития и любопытства ради. Когда вышла книга и я её прочёл, загорелся идеей сделать визуализатор, но отложил в долгий ящик, вот наконец руки дошли. Думаю в основном пригодится как раз на собеседованиях, показать общую эрудицию, ну и местами где может понадобиться производительность и где могут быть жесткие рамки по памяти, на больших объёмах данных. А так согласен с точкой зрения, сам пока не сталкивался в работе с этим, кроме циклических ссылок и работы со сборщиком мусора местами, но это было скорее исключение
Пожалуйста, рад что статья понравилась. Да нормальный вопрос, если будет что выводить, то скорее всего через Fragment и wallet, звезды можно сконвертировать в тонкоины, а их уже в кошельке можно на бирже продать за рубли. Я нахожусь в России, выбрал такой вариант, просто потому что захотелось так попробовать, люблю экспериментировать)
Безусловно вы можете так считать, ваше право, но немного обидно конечно, но например лично мне таблицы нравятся и форматирование такое я считаю уместным, тк читается легче, чем когда всё сплошным текстом(перечитывал много раз прежде чем опубликовывать), а объяснения такие, чтоб новички и люди, не разбиравшиеся в теме, тоже поняли о чем речь, уровень сложности статьи как бы намекает, ну и код из последнего примера ии вам точно не сгенерит(можете конечно поразвлекаться и попробовать)
Спасибо, что обратили внимание! Насчёт `from src.postgres.models.base import Base` — вы правы, это действительно отголосок первоначальной задумки. Изначально я хотел использовать базовый класс Base для всех моделей, но потом перешёл на другой подход, для репозитория нужно использовать другой класс, а в статье забыл обновить этот момент в процессе редактирования. Сейчас там используется более подходящий вариант —
from litestar.plugins.sqlalchemy import base
Исправлю в тексте, чтобы не вводить в заблуждение!
Про pathlib скажу, что он действительно удобнее, os.path использовал как говориться "по-умолчанию", по привычке. Пожалуй, внесу эту правку в код. Спасибо за полезный комментарий!
Добрый день, так же прошу прощения, что долго не мог ответить. Спасибо за ваш комментарий. Вы совершенно правы, uv действительно умеет устанавливать разные версии Python, и это одна из его крутых фишек. Давайте я объясню, почему я всё-таки использовал pyenv. Дело в том, что pyenv и uv решают немного разные задачи, хотя их функциональность и пересекается. pyenv я использовал как проверенный инструмент для управления версиями Python на уровне системы — он позволяет быстро переключаться между глобальными или локальными версиями интерпретатора и держать всё это под контролем через .python-version. Это особенно удобно, когда работаешь с несколькими проектами, где могут быть разные требования к версиям Python, и хочется, чтобы переключение происходило автоматически при входе в директорию (в связке с direnv, например). В момент написания статьи я решил использовать uv больше как пакетный менеджер и "ускоритель" для работы с зависимостями, а установку версий Python доверил pyenv, чтобы показать их в связке. Возможно, это и правда избыточно. И на тот момент в uv не было 13-ой версии, либо я не обновил его, если она там была и не увидел.
Добрый день, прошу прощенья, что долго не мог ответить. Благодарю за такой подробный и вдумчивый комментарий — это правда здорово, что вы так глубоко погрузились в статью и поделились своими мыслями!
Давайте разберём всё по порядку, и я с радостью отвечу на ваши вопросы, а заодно попрошу у вас совета — вдруг вы подскажете что-то, что я упустил.
Вы абсолютно правы, что набор инструментов может показаться избыточным — и это прекрасный повод для диалога! Я выбирал их с прицелом на эксперимент: попробовать что-то новое, посмотреть, как это работает в связке, и поделиться впечатлениями с читателями. Например, direnv я взял, чтобы автоматизировать активацию окружения без лишних действий — заходишь в папку, и всё само подхватывается. Но вы верно заметили, что скрипт в .envrc можно было бы упростить или вообще обойтись без него, добавив пару строк в общий баш-скрипт. Это отличная идея! Может, у вас есть пример скрипта, который вы используете в своих проектах? Было бы здорово сравнить варианты. Про pyenv + uv + direnv — да, тут действительно получается "много слоёв". Моя цель была показать, как эти инструменты могут дополнять друг друга: pyenv для версий Python, uv для скорости и удобства управления зависимостями, а direnv для локальной настройки. Но я полностью согласен, что в продакшене это может быть перебор. Кстати, про make — я добавил его для удобства, чтобы команды были под рукой, про scons, я кстати раньше не слышал, спасибо почитаю на досуге, что это за штука такая. А как вы автоматизируете свою "рутину", чтобы не плодить лишние инструменты? Про несколько версий Python под Linux — в статье я хотел показать, как pyenv может помочь с этим, я им реально пользуюсь, так как в нём больше всего вариантов разных версий Python, под каждый рабочий проект подбираю нужную, по необходимости. Конечно, тут, достаточно было бы, просто использовать uv, он это позволяет, но на тот момент там не было 13-ой версии, либо я не обновил его, если она там была и не увидел. И про HTTP/3 и nginx — отличное замечание! Granian пока действительно не поддерживает HTTP/3, и в продакшене это может быть ограничивающим фактором. В данном случае 3-ья версия протокола и не требовалась, более интересно посмотреть на производительность. Если не затруднит, расскажите, пожалуйста, как вы видите идеальный сетап для такого проекта — может, я что-то упустил из этого и попробовав добавлю в следующую часть статьи 😊 Ещё раз благодарю за ваш комментарий!
В целом, да, для общего развития и любопытства ради. Когда вышла книга и я её прочёл, загорелся идеей сделать визуализатор, но отложил в долгий ящик, вот наконец руки дошли. Думаю в основном пригодится как раз на собеседованиях, показать общую эрудицию, ну и местами где может понадобиться производительность и где могут быть жесткие рамки по памяти, на больших объёмах данных. А так согласен с точкой зрения, сам пока не сталкивался в работе с этим, кроме циклических ссылок и работы со сборщиком мусора местами, но это было скорее исключение
Спасибо, за предложение, записал себе в доработки
Совершенно верно, спасибо, что заметили, добавлю комментарий в статью
Большое спасибо за звезду - это лучшая мотивация
Очень приятно!
Рад, что пригодилось
Спасибо, что написали первым! Приятно, что материал оказался полезным
Из коробки, в коде ничего не настраивал, но там только установки/удаления
Пожалуйста, рад что статья понравилась. Да нормальный вопрос, если будет что выводить, то скорее всего через Fragment и wallet, звезды можно сконвертировать в тонкоины, а их уже в кошельке можно на бирже продать за рубли. Я нахожусь в России, выбрал такой вариант, просто потому что захотелось так попробовать, люблю экспериментировать)
спасибо, учту в следующих статьях
Да, пожалуйста, на счёт ссылок подумал так удобно будет, часть какую-то почитал, если что-то заинтересовало посмотрел, как в книге сноски
Безусловно вы можете так считать, ваше право, но немного обидно конечно, но например лично мне таблицы нравятся и форматирование такое я считаю уместным, тк читается легче, чем когда всё сплошным текстом(перечитывал много раз прежде чем опубликовывать), а объяснения такие, чтоб новички и люди, не разбиравшиеся в теме, тоже поняли о чем речь, уровень сложности статьи как бы намекает, ну и код из последнего примера ии вам точно не сгенерит(можете конечно поразвлекаться и попробовать)
Позвольте, поинтересоваться, причем тут ИИ?
блин, сейчас поправлю, спасибо
Спасибо, что обратили внимание! Насчёт `from src.postgres.models.base import Base` — вы правы, это действительно отголосок первоначальной задумки. Изначально я хотел использовать базовый класс Base для всех моделей, но потом перешёл на другой подход, для репозитория нужно использовать другой класс, а в статье забыл обновить этот момент в процессе редактирования. Сейчас там используется более подходящий вариант —
Исправлю в тексте, чтобы не вводить в заблуждение!
Про pathlib скажу, что он действительно удобнее, os.path использовал как говориться "по-умолчанию", по привычке. Пожалуй, внесу эту правку в код. Спасибо за полезный комментарий!
Добрый день, так же прошу прощения, что долго не мог ответить. Спасибо за ваш комментарий.
Вы совершенно правы, uv действительно умеет устанавливать разные версии Python, и это одна из его крутых фишек. Давайте я объясню, почему я всё-таки использовал pyenv.
Дело в том, что pyenv и uv решают немного разные задачи, хотя их функциональность и пересекается. pyenv я использовал как проверенный инструмент для управления версиями Python на уровне системы — он позволяет быстро переключаться между глобальными или локальными версиями интерпретатора и держать всё это под контролем через .python-version. Это особенно удобно, когда работаешь с несколькими проектами, где могут быть разные требования к версиям Python, и хочется, чтобы переключение происходило автоматически при входе в директорию (в связке с direnv, например).
В момент написания статьи я решил использовать uv больше как пакетный менеджер и "ускоритель" для работы с зависимостями, а установку версий Python доверил pyenv, чтобы показать их в связке. Возможно, это и правда избыточно. И на тот момент в uv не было 13-ой версии, либо я не обновил его, если она там была и не увидел.
Добрый день, прошу прощенья, что долго не мог ответить. Благодарю за такой подробный и вдумчивый комментарий — это правда здорово, что вы так глубоко погрузились в статью и поделились своими мыслями!
Давайте разберём всё по порядку, и я с радостью отвечу на ваши вопросы, а заодно попрошу у вас совета — вдруг вы подскажете что-то, что я упустил.
Вы абсолютно правы, что набор инструментов может показаться избыточным — и это прекрасный повод для диалога! Я выбирал их с прицелом на эксперимент: попробовать что-то новое, посмотреть, как это работает в связке, и поделиться впечатлениями с читателями. Например, direnv я взял, чтобы автоматизировать активацию окружения без лишних действий — заходишь в папку, и всё само подхватывается. Но вы верно заметили, что скрипт в .envrc можно было бы упростить или вообще обойтись без него, добавив пару строк в общий баш-скрипт. Это отличная идея! Может, у вас есть пример скрипта, который вы используете в своих проектах? Было бы здорово сравнить варианты.
Про pyenv + uv + direnv — да, тут действительно получается "много слоёв". Моя цель была показать, как эти инструменты могут дополнять друг друга: pyenv для версий Python, uv для скорости и удобства управления зависимостями, а direnv для локальной настройки. Но я полностью согласен, что в продакшене это может быть перебор.
Кстати, про make — я добавил его для удобства, чтобы команды были под рукой, про scons, я кстати раньше не слышал, спасибо почитаю на досуге, что это за штука такая. А как вы автоматизируете свою "рутину", чтобы не плодить лишние инструменты?
Про несколько версий Python под Linux — в статье я хотел показать, как pyenv может помочь с этим, я им реально пользуюсь, так как в нём больше всего вариантов разных версий Python, под каждый рабочий проект подбираю нужную, по необходимости. Конечно, тут, достаточно было бы, просто использовать uv, он это позволяет, но на тот момент там не было 13-ой версии, либо я не обновил его, если она там была и не увидел.
И про HTTP/3 и nginx — отличное замечание! Granian пока действительно не поддерживает HTTP/3, и в продакшене это может быть ограничивающим фактором. В данном случае 3-ья версия протокола и не требовалась, более интересно посмотреть на производительность.
Если не затруднит, расскажите, пожалуйста, как вы видите идеальный сетап для такого проекта — может, я что-то упустил из этого и попробовав добавлю в следующую часть статьи 😊
Ещё раз благодарю за ваш комментарий!