Вышел 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/
Please open Telegram to view this post
VIEW IN TELEGRAM
⚡️ Базовая аутентификация в Django: как сделать правильно
В статье рассматривается, как настроить базовую (Basic) аутентификацию в Django для API и защищённых ресурсов.
Что такое Basic Authentication
Это самый простой способ аутентификации по HTTP: клиент отправляет логин и пароль в заголовке
Django по умолчанию не предоставляет Basic Auth для view-функций. Он есть только в Django REST Framework. Если нужен собственный API или простая защита эндпоинтов без DRF — придётся реализовать самому.
Подход из статьи
Автор показывает, как создать middleware или декоратор, который:
- проверяет заголовок
- декодирует базу64
- валидирует логин/пароль
- возвращает 401 Unauthorized, если аутентификация не прошла
Пример (упрощённо):
1) Извлекаем заголовок
2) Проверяем, что он начинается с
3) Декодируем base64
4) Сравниваем с нужными учётками
Для Django-view это можно обернуть в декоратор и использовать так:
Плюсы
– очень лёгкий способ защитить API
– работает без дополнительных библиотек
– гибко настраивается
Минусы
– нет сессий, токенов, CSRF и других продвинутых схем
– подходит только под HTTPS
– пароль передаётся в каждом запросе
Кому полезно
Если нужен простой API или внутренняя служба, где полноценный OAuth/JWT:
https://adamj.eu/tech/2025/12/08/django-basic-authentication/
В статье рассматривается, как настроить базовую (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/
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
Please open Telegram to view this post
VIEW IN TELEGRAM
Владение Docker - навык, который отличает новичка от профи,
Сегодня почти всё разворачивается в контейнерах.
Если ты не умеешь работать с Docker, ты медленнее, зависим от чужих настроек и постоянно ловишь баги «у меня локально работает».
• как упаковывать проекты в контейнеры
• как поднимать целые системы за минуты
• как избегать типичных ошибок в продакшене
• как делать стабильные и повторяемые окружения
•в нем разобраны все возможные ошибки
Только практика и реальные кейсы от авторов Docker Академии- с нуля до уверенного уровня.
🎁 Скидка 40 процентов действует 48 часов
👉 Записывайся и сделай Docker своим настоящим рабочим инструментом.
Please open Telegram to view this post
VIEW IN TELEGRAM
🚀 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
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
This media is not supported in your browser
VIEW IN TELEGRAM
Идеальный старт для проекта Django: конфигурация окружения.
Сохрани себе идеальный шаблон virtual environment и основных настроек для каждого нового проекта 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
Никогда не делай тяжёлую логику в 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 не заставляет делать так, но большие проекты без этого долго не живут.
Please open Telegram to view this post
VIEW IN TELEGRAM
Ты научишься делать те, которые живут в проде.
Это не про BeautifulSoup ради галочки.
Это про системы сбора данных, которые:
• не падают от мелких правок на сайте
• собирают данные в разы быстрее
• обновляют всё сами по расписанию
• обходят ограничения и баны
• выглядят как сервис, а не хаос из файлов
Ты начнёшь видеть сайты не как страницы, а как источники данных, к которым можно подключиться.
В итоге ты сможешь:
• забирать данные для своих проектов
• автоматизировать чужую рутину
• делать инструменты для аналитики
• брать коммерческие заказы на сбор данных
Это навык, который напрямую превращается в деньги.
Не “знаю Python”, а умею добывать данные из интернета профессионально.
🎁 48 часов скидка 50% на Stepik: https://stepik.org/a/269942/
Please open Telegram to view this post
VIEW IN TELEGRAM
🐍 Полезный Django-совет
Если вы работаете с Django ORM и выбираете связанные объекты,
не делайте лишние запросы к базе.
Частая ошибка:
Если у вас 100 постов — Django сделает 101 SQL-запрос
(1 для постов + 100 для авторов).
Это называется N+1 проблема.
Исправляется одной строкой:
Теперь Django сделает один JOIN-запрос,
и все авторы загрузятся сразу.
Когда использовать:
select_related() - для ForeignKey и OneToOne
prefetch_related() - для ManyToMany и reverse relations
posts = Post.objects.prefetch_related("tags")
💡 Правило:
если вы обращаетесь к связанным объектам в цикле - почти всегда нужен select_related или prefetch_related.
Это может ускорить страницу в десятки раз.
#django #python
Если вы работаете с 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