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

В этой статье авторы продвигают идею монорепозиториев, постоянно ссылаясь на Google и Facebook. Несмотря на то, что они явно влюблены в идею монореп и из-за этого несколько необъективны, я все-таки рекомендую потратить время на статью:

1. Если просто интересно, что такое монорепа и как с ней работать
2. Там показана действительно интересная работа со сложными github actions и я для себя узнал много полезного

https://monadical.com/posts/from-chaos-to-cohesion.html

Разработка REST Api кажется простым делом - перекладывай json-чики с места на место и все дела. Но когда ты сталкиваешься с плохо спроектированными Api-шками и начинаешь задумываться о том, как спроектировать хорошо, тут то и открывается бездна. Особенно интересно то, что каждый знает "как правильно проектировать Api" и часто даже в небольшой команде начинаются жаркие споры и каждый тянет одеяло на себя.

Вот еще одна из миллиона статей на тему "как делать правильно", которая мне понравилась взвешенным подходом и подробной аргументацией к каждому пункту. Если вы работаете на проектах, где нет внутреннего стандарта на Api, то рекомендую почитать https://github.com/stickfigure/blog/wiki/How-to-(and-how-not-to)-design-REST-APIs

Вышел Django 5.0. Из более-менее интересных изменений - поддержка database defaults для полей моделей, в целом выглядит как "технический" релиз https://www.djangoproject.com/weblog/2023/dec/04/django-50-released/

Я в последнее время активно играюсь с FastStream — это такой приятный фреймворк для работы с очередями и наследник FastKafka. Сейчас уже поддерживает Kafka, Rabbit и NATS и вот в последнем релизе они добавили поддержку redis. Если вам нужен фреймворк для написания продюсеров/консьюмеров то прямо рекомендую посмотреть https://github.com/airtai/faststream

Любопытное исследование вопроса - как побыстрее прочитать много данных из Excel в питоне. Я открыл для себя много нового - например я раньше не слышал про python-calamine и не знал что DuckDb можно использовать для чтения экселя. Идеального универсального решения как обычно не завезли - например, calamine супер-быстрый, но при этом там нет возможности читать построчно итератором - все загружается сразу в память. В общем если вам приходится работать с экселем - рекомендую почитать https://hakibenita.com/fast-excel-python

Ребята, которые сделали ruff, выпустили свой тул для работы с зависимостями для python - uv. Они позиционируют его как замену pip, pip-tools и virtualenv. Написан на расте, поэтому работает быстро.

Также они взяли на себя дальнейшую поддержку rye (который изначально сделал Армин Ронахер, автор flask) и судя по всем планируют постепенно эти проекты объединить в один.

Выглядит вкусно, попробую поиграться с uv на пет-проектах.

Анонс: https://astral.sh/blog/uv
Репозиторий проекта: https://github.com/astral-sh/uv

Легкое чтение на выходные: автор напоминает, что прежде, чем делать pip install klevaya_liba желательно сначала посмотреть, насколько эта либа живая.

В качестве примера приводит Flask-Mail, у которого последний коммит был в 2014 году, но при этом почти полмиллиона скачиваний в месяц.

Это значит, что найденные проблемы в безопасности не исправляются, а совместимость с новой версией питона может отвалиться в любой момент (например, как это случилось с python-kafka и 3.12).

Статья https://freelancefootprints.substack.com/p/abandoned-code-the-hidden-risks-of

Вышел ruff 0.3.0 - которую авторы позиционируют как первую стабильную production-ready версию линтера. Что нового:

- новый style guide, основная идея которого - быть ближе к тому, как форматирует black
- улучшенная поддержка частичного форматирования - когда надо отформатировать не весь файл, а только выделенные строки в ide или только изменённые строки в пре-коммите
- автоматическое форматирование плейсхолдеров внутри f-строк

Подробности в блоге astral https://astral.sh/blog/ruff-v0.3.0

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

И в принципе он не так уж не прав - например кеширования пароля в открытом виде действительно может привести к неожиданным побочкам. Думать, что и как ты кешируешь (да и в целом думать) - полезно, но вот объявлять кеширование в целом security risk-ом — это что-то новенькое 😉

У меня нет доступа к gemini pro, но в целом я готов поверить в такое поведение, пока все что показывал Гугл как минимум "странное" https://new.pythonforengineers.com/blog/so-evidently/

Друзья, хотим рассказать замечательную новость - конференции про Python от нашего сообщества - быть!

Как и в прошлом году, мы встречаемся на Positive Hack Days - 26-го мая мы проведём там Python Day.

Спикеры и гости конференции Python Day будут иметь доступ ко всем техническим трекам на Positive Hack Days в течение всего времени проведения фестиваля.

Планируем целый день докладов и дискуссий про Python. И поэтому мы открываем CFP - ждём ваших заявок на доклады до конца марта.

Мы рассчитываем, что на Python Day придёт порядка 500 профессиональных разработчиков на Python (Middle, Middle+ и Senior) и очень хотим сделать интересную программу для них.

Мы не ограничиваем темы докладов - ожидаем от вас лишь интересных кейсов и знаний в сфере разработки на Python. Время на выступление - порядка 40 минут + 10 минут на вопросы из зала.

ВАЖНО: Чем раньше вы подадите заявку, тем больше времени у ПК будет на её рассмотрение.

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

Заявки на доклады можно подавать тут:
https://docs.google.com/forms/d/e/1FAIpQLSdfWqy2eSlLOcpR6BzHp0ypUqFSBBWrUBgb0ZveD1oKPqOmoQ/viewform

psycopg3 вышла уже почти три года назад, но я уверен, что многие пока по разным причинам сидят на psycopg 2. Вот тут померяли скорость работы psycopg2 vs psycopg3 и результаты на мой взгляд получились неоднозначные:

1. В обычных select from запросах psycopg3 в три раза быстрее psycopg2. Кажется для большинства проектов, у которых чтения больше записи переход вполне оправдан
2. А вот на всяких более редких кейсах типа batch-записи или получения blob-ов из базы тройка проигрывает двойке

В общем я задумался о том, чтобы проекты, где под капотом psycopg начать переводить на третью версию https://www.timescale.com/blog/psycopg2-vs-psycopg3-performance-benchmark/

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

И вот тут мне прямо хорошо зашла тула https://github.com/rohaquinlop/complexipy - это штука для оценки cognitive complexity (можно почитать тут https://habr.com/ru/articles/565652/).

На самом деле есть разные тулы для этого, но complexipy мне понравился скоростью, довольно гибкими настройками и в хорошем смысле замороченностью автора, который пошел за ревью к G. Ann Campbell, которая собственно основной автор методики.
Конечно, у любой методики оценки качества кода есть свои минусы, но чем мне нравится этот конкретный вариант - он хорошо показывает куда смотреть и где скорее всего код требует рефакторинга.