Django Python Telegram Channel Link

django-upgrade-report. Показывает, какие зависимости блокируют апгрейд Django и в каком порядке их обновлять.https://github.com/derblub/django-upgrade-report

🐍 Какая зависимость держит ваш Django на старой версии?django-upgrade-report читает зависимости проекта, проверяет заявленную совместимость на PyPI и составляет план обновления:- Какие пакеты блокируют переход.- Что можно обновить заранее.- Что нужно обновлять одновременно с Django.- Где потребуется ручная проверка.Поддерживает lock-файлы uv, Poetry, PDM, Pipenv и requirements.txt. Подбирает минимальную подходящую версию пакета, чтобы сократить масштаб изменений.Запуск из папки проекта:uvx django-upgrade-reportОтчёт можно сохранить в HTML, Markdown или JSON и подключить к CI. Совместимость оценивается по метаданным пакетов, поэтому тесты проекта всё равно нужны.https://github.com/derblub/django-upgrade-report

Вопросы на собеседовании Python Senior: 100 вопросов с ответами (2026)Вопросы на собеседовании Python Senior с ответами: 100 вопросов и примеры кода — CPython, GIL, asyncio, метаклассы, типизация, производительность, Python 3.14.https://uproger.com/voprosy-na-sobesedovanii-python-senior/

🔥 Django Q() objects — один из самых полезных инструментов ORM, который многие используют слишком редкоQ() позволяет собирать сложные условия для WHERE, комбинируя их через AND, OR и NOT.Пример:Pet.objects.filter( Q(last_given_treats__isnull=True) | Q(last_given_treats__lte=timezone.now() - timedelta(days=1)), treats_needed__gt=F("treats_given"),)Особенно полезно для динамических фильтров:q = Q()for term in search_term.split(): q |= Q(name__icontains=term)Pet.objects.filter(q)Но есть ещё более важный момент.При фильтрации через related models два отдельных .filter() могут привести к двум JOIN и неожиданно изменить смысл запроса.Species.objects.filter( pets__name__icontains="meowy").filter( pets__treats_given=0)Это уже может искать одну запись по имени, а другую - по количеству treats.Если собрать условия в одном .filter() или через Q(), Django использует один JOIN и проверяет условия на одной и той же связанной записи.Очень полезный приём для сложных QuerySet, динамического поиска и composable business filters.https://www.better-simple.com/django/2026/09/09/nifty-feature-q-objects/

🔥 Хак в Django: Meta.indexes можно использовать для собственных миграцийОказывается, models.Index в Django можно превратить почти в универсальную migration-операцию.Идея:class CustomMigrationOperation(models.Index): def create_sql(self, model, schema_editor, **kwargs): ... def remove_sql(self, model, schema_editor, **kwargs): ...А затем добавить её прямо в модель:class Meta: indexes = [CustomMigrationOperation()]После этого makemigrations сам подхватит изменение, а migrate выполнит нужный SQL.Почему это работает:Index уже умеет генерировать SQL через create_sql() и remove_sql().Так можно описывать не только индексы, но и:triggerstable commentssecurity labelsдругие schema-level настройкиАвтор использовал этот приём для PostgreSQL Anonymizer, чтобы правила анонимизации жили рядом с моделью и автоматически попадали в миграции.Подход довольно hacky, но как способ расширить механизм миграций Django — очень интересный.https://www.better-simple.com/django/2026/09/02/nifty-feature-use-index-for-custom-migrations/

Нечёткий поиск в Django + PostgreSQL можно сделать намного умнее обычного icontains.В Caktus Group разобрали fuzzy string matching средствами самого PostgreSQL - без отдельного Elasticsearch.Идея проста: вместо точного совпадения искать строки, похожие друг на друга.Для этого в PostgreSQL можно использовать:- pg_trgm- trigram similarity- Django TrigramSimilarity- пороги похожести- GIN/GiST индексы для ускорения поискаНапример, пользователь вводит имя с опечаткой, переставляет буквы или пишет только часть слова - а приложение всё равно находит нужную запись.Особенно полезно для поиска по именам, адресам, названиям компаний и любым пользовательским данным, где идеального ввода ждать не стоит.https://www.caktusgroup.com/blog/2026/08/21/fuzzy-string-matching-django-postgresql/

🐍 Django-разработчикам: `DEBUG=True` в проде опаснее, чем кажется.Это не просто красивые страницы ошибок. При включённом DEBUG приложение может раскрывать stack trace, настройки, пути файлов, middleware, URL-паттерны и другие детали окружения.Главная рекомендация - fail closed:DEBUG = FalseТо есть по умолчанию DEBUG всегда выключен, а включается только локально.Даже staging, QA и preview-среды, доступные из интернета, лучше запускать с DEBUG=False.Отдельная ловушка - переменные окружения:DEBUG = os.environ.get("DEBUG", "False") != "False"Здесь DEBUG=false или DEBUG=0 могут неожиданно превратиться в True.Лучше явно парсить boolean или использовать django-environ.Мелкая настройка, которая однажды может спасти production от очень неприятной утечки.https://lincolnloop.com/blog/setting-djangos-debug-safely/#Python #Django #Backend #Security #DevOps

🚀 Django 6.1 вышел: меньше магии, больше контроляНовая версия Django приносит улучшения для production-приложений и работы с базой данных.Главное новшество — новый подход к загрузке данных моделей.Теперь можно контролировать, когда Django делает дополнительные запросы:from django.db import modelsbooks = Book.objects.fetch_mode( models.FETCH_PEERS)Это помогает бороться с проблемой N+1 запросов и лучше контролировать нагрузку на БД.Новые режимы:- FETCH_ONE — загружать данные только для текущего объекта;- FETCH_PEERS — догружать данные сразу для группы объектов;- RAISE — запрещать неожиданные запросы и ловить проблемы заранее.Также в Django 6.1:- поддержка Python 3.12, 3.13 и 3.14;- PostgreSQL 15+;- MySQL 8.4+;- MariaDB 10.11+;- улучшения cache и внутренних механизмов.Главная идея релиза:Django всё меньше скрывает стоимость операций и даёт разработчикам больше контроля над тем, что происходит под капотом.Подробнее:https://www.djangoproject.com/weblog/2026/aug/05/django-61-released/

⚡️ django-orjson ускоряет работу Django с JSONAdam Johnson выпустил библиотеку django-orjson с готовыми заменами стандартных JSON-компонентов Django и Django REST Framework.В основе лежит написанный на Rust orjson:- сериализация до 10 раз быстрее;- десериализация примерно в 2 раза быстрее.Поддерживаются:- JsonResponse и тестовый клиент;- json_script;- сериализаторы, сессии и signing;- компоненты Django REST Framework.Пакет протестирован на поддерживаемых версиях Python и Django, заявлено 100% покрытие ветвей.Также обсуждается подключаемый JSON-бэкенд для самого Django. Тогда стандартный json можно будет заменить на orjson централизованно, без изменения импортов по всему проекту.https://adamj.eu/tech/2026/07/15/introducing-django-orjson/

Wagtail как Django admin на стероидахХороший разбор для Django-разработчиков: Wagtail можно использовать не только как CMS, но и как более удобную админку для обычных Django-моделей.Смысл простой: Django admin быстро даёт UI вокруг моделей, но кастомизация часто превращается в боль. Wagtail даёт более современный интерфейс, нормальную работу с полями, группировку через panels, роли, permissions, rich text, media library, versioning и редакторские workflow.При этом не нужно переписывать проект под CMS-логику. Wagtail ставится как обычный Django-пакет, добавляется в INSTALLED_APPS, подключается в urls.py, а бизнес-логика, views, forms и templates остаются обычными Django.Самый практичный случай использования : взять существующий admin.py, перенести модели в Wagtail snippets и постепенно заменить старую админку там, где нужен интерфейс, который не стыдно показать клиенту.Для внутренних тулзов, CRM, backoffice и контентных разделов это может быть намного приятнее, чем бесконечно допиливать стандартный Django admin.https://timonweb.com/wagtail/wagtail-as-django-admin-on-steroids/

Вышел Django 6.0.Релиз получился не про косметику, а про вещи, которые давно просились в core.Главное - встроенная поддержка Content Security Policy.Теперь CSP можно настраивать прямо в Django через middleware, context processor и настройки SECURE_CSP / SECURE_CSP_REPORT_ONLY. Это упрощает защиту от XSS и content injection без отдельного пакета.Второе важное изменение - template partials.В шаблонах появились {% partialdef %} и {% partial %}. Можно описывать небольшие переиспользуемые фрагменты прямо внутри template-файла, а не дробить всё на отдельные include.Третье - встроенный Tasks framework.Django теперь умеет описывать и ставить фоновые задачи в очередь. Но важно: воркер в комплект не входит. Запуск задач всё равно остаётся за внешним процессом или инфраструктурой.Ещё из полезного:• поддержка Python 3.12, 3.13 и 3.14• современный Python email API• AsyncPaginator• StringAgg теперь не только для PostgreSQL• forloop.length в шаблонах• DEFAULT_AUTO_FIELD теперь по умолчанию BigAutoFieldПеред обновлением стоит внимательно пройтись по breaking changes: Python ниже 3.12 больше не поддерживается, MariaDB 10.5 тоже выпала, а часть email API и ORM-кастомизаций может потребовать правок.Документация:https://docs.djangoproject.com/en/6.0/releases/6.0/

🖥 GitHub Pages можно пересобрать почти на голом Python.Автор показал, как сделать лёгкую платформу для хостинга статических сайтов без фреймворков и тяжёлой инфраструктуры. Только стандартная библиотека Python.Идея простая:• http.server отдаёт статические файлы• небольшой Python-код добавляет логику деплоя• автоматизация обновляет сайт после изменений• HTTPS можно прикрутить без отдельного большого стекаГлавный кайф не в том, чтобы «убить GitHub Pages», а в том, чтобы понять механику под капотом.Статический хостинг - это не магия. Это файловая раздача, маршруты, деплой, сертификаты и немного аккуратной автоматизации.Хороший материал для тех, кто хочет лучше понимать web-инфраструктуру, а не просто нажимать кнопку Deploy.https://blog.klemek.fr/articles/2026-06-14/

🐍 Python Roadmap 2026: наконец-то полноценная актуальная карта изучения Python, а не список ссылок «разберись сам»На GitHub выложили большой русскоязычный роадмап по Python на 2026 год - от первых скриптов до уровня Middle+/Senior. Маршрут собран под современный Python:- Python 3.13+- free-threaded mode без GIL- JIT- uv вместо боли с pip/venv/poetry- ruff, pyright, pytest, hypothesis- async-first подход- типизация- CPython внутри- web, базы, ML/AI, DevOps и архитектураВ роадмапе есть нормальная последовательность: сначала окружение и база, потом идиомы, ООП, типы, стандартная библиотека, асинхронность, тестирование, внутренности CPython, web, базы данных, AI-направление, продакшн и архитектура.Отдельный плюс - практический формат. На каждом этапе есть задачи, чеклисты, примеры кода и бесплатные ресурсы. То есть это не мотивационная простыня, а маршрут, по которому реально можно идти несколько месяцев и видеть прогресс.Для новичков - понятный путь без хаоса.Для джунов - способ закрыть дыры.Для тех, кто уже пишет на Python - хороший чеклист, чтобы понять, где ты всё ещё плаваешь.Python в 2026 году - это tooling, типы, async, инфраструктура, AI и продакшн-дисциплина. И этот роадмап как раз про такой Python.https://github.com/justxor/pythonroamap2026

🐍 Полезный Django-советЕсли вы работаете с Django ORM и выбираете связанные объекты, не делайте лишние запросы к базе.Частая ошибка:for post in Post.objects.all(): print(post.author.name)Если у вас 100 постов — Django сделает 101 SQL-запрос(1 для постов + 100 для авторов).Это называется N+1 проблема.Исправляется одной строкой:posts = Post.objects.select_related("author")for post in posts: print(post.author.name)Теперь Django сделает один JOIN-запрос,и все авторы загрузятся сразу.Когда использовать:select_related() - для ForeignKey и OneToOneprefetch_related() - для ManyToMany и reverse relationsposts = Post.objects.prefetch_related("tags")💡 Правило:если вы обращаетесь к связанным объектам в цикле - почти всегда нужен select_related или prefetch_related.Это может ускорить страницу в десятки раз.#django #python

✔️ Лови полезный Django-совет, который спасает продакшен чаще, чем кажется.Никогда не делай тяжёлую логику в Django views.Новички часто пихают всё прямо во view:- бизнес-логику - валидацию - расчёты - работу с БД - интеграции В итоге получается "божественная функция" на 200 строк, которую невозможно тестировать и поддерживать.Правильный подход — разделять слои:- View — только принимает запрос и отдаёт ответ - Services / use-cases — бизнес-логика - Models — работа с данными - Serializers / Forms — валидация Плохо:def create_order(request): user = request.user items = request.data['items'] total = 0 for item in items: product = Product.objects.get(id=item['id']) total += product.price * item['qty'] order = Order.objects.create(user=user, total=total) ...Лучше:# services/order_service.pydef create_order(user, items): total = calculate_total(items) return Order.objects.create(user=user, total=total)# views.pydef create_order_view(request): order = create_order(request.user, request.data['items']) return Response({"id": order.id})Почему это важно:• проще тестировать• код переиспользуется• view не превращается в монстра• легче менять логику, не трогая APIDjango не заставляет делать так, но большие проекты без этого долго не живут.

Идеальный старт для проекта Django: конфигурация окружения.Сохрани себе идеальный шаблон virtual environment и основных настроек для каждого нового проекта Django. Это упростит процесс настройки окружения и позволит избежать распространенных ошибок.# Создание виртуального окруженияpython3 -m venv venv# Активация виртуального окруженияsource venv/bin/activate# Установка основных зависимостейpip install django djangorestframework psycopg2# Создание файла requirements.txtpip freeze > requirements.txt# Инициализация нового проекта Djangodjango-admin startproject myproject# Переход в директорию проектаcd myproject# Запуск сервера для проверкиpython manage.py runserver

🚀 AgentCPM-Explore - первый open-source агент на 4B, который реально тащит GAIA и сложные реальные задачиOpenBMB выкатили AgentCPM-Explore - модель всего на 4B параметров, но по агентным метрикам она выглядит как зверь.✅ SOTA среди 4B агент-моделейПо агентным бенчмаркам модель:- обгоняет всех на своём масштабе- превосходит часть 8B моделей- и даже конкурирует с некоторыми 30B+ и closed-source LLM🧠 Deep Research как у “исследователя”Модель умеет:- длинные цепочки рассуждений (long-horizon reasoning)- 100+ ходов автономного диалога- проверять себя через несколько источников (cross-validation)- делать самокоррекцию как человек- динамически менять стратегию и использовать инструментыТо есть это уже не “чатбот”, а мини-исследователь, который реально может вести задачу до конца.🔓 Открыт не только модельный вес - открыт весь стекИ это самое жирное: OpenBMB выкладывают не “голую модель”, а весь pipeline агентности:- AgentRL - асинхронный RL-фреймворк для обучения агентов - AgentDock - безопасная песочница инструментов (tool sandbox) - AgentToLeaP - платформа оценки tool-learning (в один клик) - полный датапайплайн и воспроизводимые training workflowsЭто полноценная open-source платформа для создания агентов, где можно реально учиться, экспериментировать и собирать своих автономных “ресёрчеров”.Кто уже тестил GAIA на своих агентах ?🤗 Hugging Face: https://huggingface.co/openbmb/AgentCPM-Explore 🔗 GitHub: https://github.com/OpenBMB/AgentCPM

🖥 FastAPI для клиента: как должны выглядеть API-клиенты в PythonPython-сообщество отлично научилось делать API-серверы.FastAPI / DRF дают идеальный опыт разработчика:- типы- валидация- понятные эндпоинты- документация по OpenAPI- минимум рутиныНо есть проблема.Серверы стали удобными и “правильными”, а вот клиентская сторона до сих пор часто выглядит как кустарщина.Что часто встречается в проектах на базе python: - везде раскиданы httpx.get/post- URL собираются руками- параметры и headers копируются по коду- ответы парсятся вручную- ошибки обрабатываются как попало- нет нормальных типов и автодополненияИ именно тут часто появляется 80% проблем.API может быть идеально спроектирован, но пользоваться им неудобно.Да, можно сгенерировать кода клиента.Но чаще всего генератор выдаёт огромный неудобный код:- странные имена методов- перегруженные классы- нечитаемый boilerplate- всё равно приходится писать обёртки рукамиВ итоге клиенты либо не генерируют вообще, либо генерируют и потом ненавидят.API-клиенты должны быть сделаны как фреймворк.Как FastAPI, только наоборот.То есть ты описываешь клиент красиво и декларативно:- функция описывает intent (что мы делаем)- типы описывают контракт- библиотека берёт на себя HTTP-рутинуВместо кода “на коленке”httpx.get("https://api.site.com/users/123")Должно бытьget_user(123)И дальше библиотека сама:- соберёт URL- подставит параметры- сериализует запрос- выполнит HTTP- распарсит ответ- кинет нормальную ошибку- даст типы и автодополнение в IDEИменно эту идею автор статье и продвигает (проект Clientele)Сделать API-клиенты удобными, чистыми и типобезопаснымитак же, как мы привыкли делать серверыПроблема не в HTTP.Проблема в том, что API-клиенты в Python до сих пор не стали “первоклассным кодом”.А должны стать.Подробности: paulwrites.software/articles/python-api-clients

⚡️ Базовая аутентификация в Django: как сделать правильноВ статье рассматривается, как настроить базовую (Basic) аутентификацию в Django для API и защищённых ресурсов.Что такое Basic Authentication Это самый простой способ аутентификации по HTTP: клиент отправляет логин и пароль в заголовке Authorization: Basic …, закодированные в base64. Подходит для API, но требует HTTPS, так как пароль передаётся в каждом запросе.Django по умолчанию не предоставляет Basic Auth для view-функций. Он есть только в Django REST Framework. Если нужен собственный API или простая защита эндпоинтов без DRF — придётся реализовать самому.Подход из статьи Автор показывает, как создать middleware или декоратор, который:- проверяет заголовок Authorization- декодирует базу64- валидирует логин/пароль- возвращает 401 Unauthorized, если аутентификация не прошлаПример (упрощённо):1) Извлекаем заголовок 2) Проверяем, что он начинается с Basic 3) Декодируем base64 4) Сравниваем с нужными учёткамиДля Django-view это можно обернуть в декоратор и использовать так:@basic_auth_requireddef my_view(request): …Плюсы– очень лёгкий способ защитить API– работает без дополнительных библиотек– гибко настраиваетсяМинусы– нет сессий, токенов, CSRF и других продвинутых схем– подходит только под HTTPS– пароль передаётся в каждом запросеКому полезноЕсли нужен простой API или внутренняя служба, где полноценный OAuth/JWT: https://adamj.eu/tech/2025/12/08/django-basic-authentication/

🖥 Django 6.0 вышел - крупное обновление фреймворкаВышел Django 6.0, и это одно из самых насыщенных обновлений за последнее время. Релиз добавляет функциональность, которую разработчики долго закрывали сторонними библиотеками или кастомными решениями.Что нового и действительно важно:Поддержка template partials из коробки Теперь Django умеет частичные шаблоны на уровне фреймворка. Это упрощает структуру HTML, повышает переиспользуемость и делает шаблоны чище и понятнее без лишних include-хаков.Нативный фреймворк для фоновых задач В Django появился встроенный механизм для background tasks. Для многих проектов это означает, что Celery или RQ больше не обязательны для базовых задач — отложенные и асинхронные операции можно реализовать стандартными средствами.Встроенная система Content Security Policy (CSP) Django 6.0 получил полноценную поддержку CSP. Это серьёзный шаг в сторону безопасности по умолчанию и защита от XSS и других атак без внешних middleware.Современный email API с нормальной Unicode-поддержкой Работа с email стала более предсказуемой и дружелюбной к Unicode, что особенно важно для международных проектов и сложных шаблонов писем.Жизненный цикл версий Django 5.2 больше не имеет mainstream-поддержки. Разработчикам рекомендуется переходить на 6.0, чтобы получать новые возможности, обновления безопасности и улучшения платформы. Django продолжает двигаться в сторону «batteries included», но делает это аккуратно и прагматично. Django 6.0 снижает зависимость от внешних библиотек, усиливает безопасность и делает повседневную разработку заметно удобнее.Это релиз, который стоит внимательно изучить и запланировать апгрейд.https://www.djangoproject.com/weblog/2025/dec/03/django-60-released/