Django Python
6.64K subscribers
128 photos
6 videos
3 files
280 links
Django

Вопросы @haarrp

all questions to @haarrp

@ai_machinelearning_big_data -ML

@ArtificialIntelligencedl -AI

@datascienceiot - ml 📚

@pythonlbooks -📚books

@hr_itwork-работа
Download Telegram
✔️ Лови полезный 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 не заставляет делать так, но большие проекты без этого долго не живут.
Please open Telegram to view this post
VIEW IN TELEGRAM
🐍 Полезный 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
🐍 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
🖥 GitHub Pages можно пересобрать почти на голом Python.

Автор показал, как сделать лёгкую платформу для хостинга статических сайтов без фреймворков и тяжёлой инфраструктуры. Только стандартная библиотека Python.

Идея простая:

http.server отдаёт статические файлы

• небольшой Python-код добавляет логику деплоя

• автоматизация обновляет сайт после изменений

• HTTPS можно прикрутить без отдельного большого стека

Главный кайф не в том, чтобы «убить GitHub Pages», а в том, чтобы понять механику под капотом.

Статический хостинг - это не магия. Это файловая раздача, маршруты, деплой, сертификаты и немного аккуратной автоматизации.

Хороший материал для тех, кто хочет лучше понимать web-инфраструктуру, а не просто нажимать кнопку Deploy.

https://blog.klemek.fr/articles/2026-06-14/
Please open Telegram to view this post
VIEW IN TELEGRAM
Вышел 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/
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-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/