Вышла первая бета Django 5.0, а значит значимого изменения состава релиза уже не будет и можно смотреть, что завезли:

1. Много поддержки асинхронности - в contrib.auth, возможность получить и обработать asyncio.CancelledError внутри вьюхи, если клиент разорвал соединение до того, как мы закончили обрабатывать запрос, поддержка асинхронки в куче декораторов, асинхронная отправка сигналов, новые асинхронные методы у моделек
2. На первом месте довольно спорная фича - возможность показывать количество фильтруемых объектов в боковом фильтре в админке. Там под капотом COUNT и естественно на более-менее приличных объемах данных тормозить будет нечеловечески. Благо можно глобально отключить
3. Упрощенная шаблонизация для форм из коробки, для тех кто работает с html-формами код станет читабельнее (хотя думается мне, что те кто работает с большими формами уже давно что-то подобное у себя реализовали)
4. Возможность задавать дефолты на уровне базы данных
5. `GENERATED`-поля в моделях, значение которых рассчитывается на уровне БД
6. В Choice-полях теперь можно использовать словарь, вместо кортежей

В общим никаких революций https://docs.djangoproject.com/en/5.0/releases/5.0/

Новости nogil. Steering Council принял PEP 703 - опциональный gil из коробки. На discuss.python.org большой пост про это, я приведу только заинтересовавшие меня моменты:

Пока нет уверенности, что выпиливание gil не поломает совместимость со сторонними либами, не сделает интерпретатор медленнее на 10–15% и не усложнит его поддержку. Выбрали вполне ожидаемый подход - реализуем и посмотрим, как пойдет, потому что на прототипах и теоретических выкладках далеко не уедешь.

Как и предполагали раньше, все будет происходить в несколько этапов:

1. Возможность отключить gil на этапе сборки — это точно не продакшен решение, а инструмент для авторов библиотек и экспериментаторов
2. Финализация изменений API и ABI, после чего nogil-сборка будет уже считаться не экспериментальной но все еще не включаться по дефолту
3. Отключенный gil по умолчанию с возможностью включить при сборке

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

https://discuss.python.org/t/pep-703-making-the-global-interpreter-lock-optional-in-cpython-acceptance/37075

Многие начинающие разработчики и даже мидлы иногда не осознают всей пользы, которую может принести использование модуля functools в Python. Если вы еще не используете functools то мы идем к вам, почитайте эту статью. В ней описано несколько практических примеров, демонстрирующих, как functools может сделать ваш код и вашу жизнь чуть лучше: https://pybit.es/articles/6-cool-things-you-can-do-with-the-functools-module/

Kenneth Reitz (автор `requests`) официально прекратил работать асинхронный requests3. Некоторое время назад он даже собирал под это дело донаты, но потом от него долго не было коммитов и статус проекта был непонятен. По его словам, асинхронка в питоне не оправдала его ожиданий и requests останутся синхронными.

На редите в комментах народ бурлит и обсуждает его в негативном ключе. Но я могу понять Кеннета - сам был в ситуациях, когда вроде обещал и понимаешь, что надо сделать, но просто не можешь заставить себя взяться за задачу (код) потому-то с души воротит. Тем более Кеннет давно писал, что у него биполярка.

В общем, если вы ждете асинхронный requests3 - имеет смысл посмотреть на альтернативы. Я лично в любом случае благодарен Кеннету за отличный requests.

https://kennethreitz.org/essays/why-im-not-collaborating-with-kenneth-reitz

23 ноября в Нижнем пройдет оффлайн-митап про python в Astra Linux, подробнее https://t.me/gkastrateam/272

Вышла Django Ninja 1.0 - это такой аналог Django Rest Framework, но несколько более быстрый из-за использования pydantic и лучшей работой с асинхронностью. Что нового:

1. Перешли на pydantic 2 (поддержку v1 дропнули)
2. Поддержка async в аутентификации
3. Много всяких других улучшений, которые мне сложно оценить так как я сам django ninja трогал совсем чуть-чуть и на реальных проектах не сталкивался

Но всех, кто пользуется, поздравляю с мажорным релизом https://django-ninja.dev/whatsnew_v1/

В последнее время монорепозитории становятся модными, по крайней мере я все чаще вижу обсуждения вроде "давайте все переходить на монорепы". Вероятно для больших компания (таких как 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