Django Python

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

🖥 Python в 2026 - уже не просто «первый язык программирования». Это инструмент, с которым можно автоматизировать задачи, писать скрипты, собирать проекты, работать с данными, делать ботов и использовать ИИ как ускоритель разработки. Но есть проблема: большинство новичков учат Python кусками. Немного синтаксиса, пару задачек, немного теории - и потом ступор: «а что с этим делать дальше?» Этот курс сделан иначе. Здесь упор на реальную практику: вы не просто смотрите уроки, а постепенно учитесь писать код, разбирать ошибки, собирать рабочие решения и понимать, как Python применяется в нормальных задачах. Что внутри: - Python с нуля понятным языком - практика вместо бесконечной сухой теории - реальные задачи и проекты - автоматизация рутины - работа с файлами, данными и API - понятная логика программирования - современный подход к разработке с ИИ - отдельный акцент на вайбкодинг Вайбкодинг -это умение правильно ставить задачу, проверять код, понимать результат и ускорять работу без слепого копирования. В 2026 году это уже не бонус, а нормальный навык разработчика. Сегодня скидка 60 процентов: https://stepik.org/course/288218/info

🐍 Полезный 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