Django Python

🔥 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().

Так можно описывать не только индексы, но и:

triggers
table comments
security 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 models

books = 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 с JSON

Adam 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 и OneToOne

prefetch_related() - для ManyToMany и reverse relations

posts = 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.py
def create_order(user, items):
    total = calculate_total(items)
    return Order.objects.create(user=user, total=total)

# views.py
def create_order_view(request):
    order = create_order(request.user, request.data['items'])
    return Response({"id": order.id})

Почему это важно:

• проще тестировать

• код переиспользуется

• view не превращается в монстра

• легче менять логику, не трогая API

Django не заставляет делать так, но большие проекты без этого долго не живут.

Идеальный старт для проекта Django: конфигурация окружения.

Сохрани себе идеальный шаблон virtual environment и основных настроек для каждого нового проекта Django. Это упростит процесс настройки окружения и позволит избежать распространенных ошибок.

# Создание виртуального окружения
python3 -m venv venv

# Активация виртуального окружения
source venv/bin/activate

# Установка основных зависимостей
pip install django djangorestframework psycopg2

# Создание файла requirements.txt
pip freeze > requirements.txt

# Инициализация нового проекта Django
django-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-клиенты в Python

Python-сообщество отлично научилось делать 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_required
def 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/

📌 Первые впечатления от системы фоновых задач в Django

В свежем разборе объясняется, как Django наконец получает встроенный инструмент для фоновой обработки заданий без необходимости тянуть сторонние библиотеки вроде Celery.

🔹 Что это такое
Django Background Tasks - новый официально поддерживаемый механизм для:
- отложенного выполнения задач (delayed jobs),
- периодических задач (cron-style),
- асинхронной фоновой обработки в рамках приложения.

🔹 Почему это важно
Раньше разработчикам приходилось выбирать сторонние решения (Celery, RQ, Dramatiq) с дополнительной инфраструктурой (Redis/RabbitMQ и т.п.). Теперь у Django будет собственный, простой и интегрированный способ:
- выполнять задачи после ответа пользователю,
- обрабатывать тяжёлые операции вне запроса,
- запускать периодические задачи без внешних кронов.

🔹 Как это работает
- Вы определяете задачу как обычную Python-функцию.
- Django регистрирует её в очереди внутреннего раннера.
- Фоновый воркер выполняет такие задачи по расписанию или сразу - без внешнего брокера.

🔹 Плюсы по сравнению с альтернативами
✔ встроенная интеграция с ORM и Django-экосистемой
✔ нет необходимости настраивать отдельный брокер
✔ ожидаемая простота и знакомый синтаксис для Django-разработчиков

🔹 О чём ещё в статье
- примеры кода с определением фоновых задач;
- как запускать и мониторить воркеры;
- ограничения и когда всё же стоит использовать более мощные системы.

📌 В сумме: Django делает шаг к тому, чтобы базовая фонвая обработка стала простой и доступной из коробки - это ускоряет разработку и снижает операционную сложность для большинства проектов.

https://roam.be/notes/2025/a-first-look-at-djangos-new-background-tasks/

🖥 Как организовать архитектуру большого Python-проекта?

Разработка крупного Python-проекта требует продуманной архитектуры. Правильная структура кода упрощает развитие, тестирование и поддержку приложения.

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

Обсудим разделение системы на слои (domain, service, infrastructure), использование популярных шаблонов проектирования (Dependency Injection, Repository, Facade), организацию кода по модулям и пакетам, примеры структуры каталогов, работу с зависимостями и конфигурацией (Pydantic, dotenv), логгирование и мониторинг, обеспечение тестируемости, поддержку расширяемости и модульности.

Также приведем примеры кода и структуры каталогов, а в конце – общие советы и распространенные ошибки, которых следует избегать.

https://uproger.com/kak-organizovat-arhitekturu-bolshogo-python-proekta/

🚀 django-keel - мощный стартовый шаблон для Django-проектов

💡 Что это такое
Готовый современный каркас для Django-приложений, который позволяет запускать новый проект за минуты — с правильной архитектурой, CI, Docker и продуманной конфигурацией.

🔥 Что внутри
- Поддержка Python 3.12+ и Django 5.2+
- Несколько видов проектов: SaaS, API-backend, web-app, internal tools
- Docker + Docker Compose
- Настроенные линтеры, тесты, coverage и GitHub Actions
- 12-factor конфигурация, разделённые settings (dev/test/prod)
- Варианты API: DRF или GraphQL
- Поддержка фронта: Next.js или HTMX + Tailwind

🎯 Почему стоит использовать
- Экономит недели рутинной настройки
- Даёт единообразную и поддерживаемую архитектуру
- Ускоряет разработку MVP, внутренних сервисов и SaaS-продуктов

🛠 Быстрый старт

copier copy gh:CuriousLearner/django-keel my-project

Репозиторий: https://github.com/CuriousLearner/django-keel