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 не заставляет делать так, но большие проекты без этого долго не живут.

🖥 Большинство “парсеров” умирают через 2 дня. Ты научишься делать те, которые живут в проде. Это не про BeautifulSoup ради галочки. Это про системы сбора данных, которые: • не падают от мелких правок на сайте • собирают данные в разы быстрее • обновляют всё сами по расписанию • обходят ограничения и баны • выглядят как сервис, а не хаос из файлов Ты начнёшь видеть сайты не как страницы, а как источники данных, к которым можно подключиться. В итоге ты сможешь: • забирать данные для своих проектов • автоматизировать чужую рутину • делать инструменты для аналитики • брать коммерческие заказы на сбор данных Это навык, который напрямую превращается в деньги. Не “знаю Python”, а умею добывать данные из интернета профессионально. 🎁 48 часов скидка 50% на Stepik: https://stepik.org/a/269942/

Идеальный старт для проекта 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

Вышли первые выпуски IT-покера от K2 Cloud Турнир, где айтишники собирают идеальные билды из карт, интуиции и навыков. Вместо привычной колоды — технологии, сервисы и архитектурные решения. Идем смотреть

🚀 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

🖥 На Stepik вышел курс, который учит работать с Docker на реальных проектах. Владение Docker - навык, который отличает новичка от профи, Сегодня почти всё разворачивается в контейнерах. Если ты не умеешь работать с Docker, ты медленнее, зависим от чужих настроек и постоянно ловишь баги «у меня локально работает». • как упаковывать проекты в контейнеры • как поднимать целые системы за минуты • как избегать типичных ошибок в продакшене • как делать стабильные и повторяемые окружения •в нем разобраны все возможные ошибки Только практика и реальные кейсы от авторов Docker Академии- с нуля до уверенного уровня. 🎁 Скидка 40 процентов действует 48 часов 👉 Записывайся и сделай Docker своим настоящим рабочим инструментом.

🖥 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 — overkill.Ссылка 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/ @pythonl

🖥 Как организовать архитектуру большого 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

🔥 Подборка полезных ресурсов для программистов. Здесь ты найдёшь всё это - коротко, по делу и без воды. Пока другие ищут, где “подглядеть решение”, ты уже используешь самые свежие инструменты! AI: t.me/ai_machinelearning_big_data Python: t.me/pythonl Linux: t.me/linuxacademiya Devops: t.me/DevOPSitsec Собеседования DS: t.me/machinelearning_interview C++ t.me/cpluspluc Docker: t.me/DevopsDocker Хакинг: t.me/linuxkalii Data Science: t.me/data_analysis_ml Javascript: t.me/javascriptv C#: t.me/csharp_1001_notes Java: t.me/java_library Базы данных: t.me/sqlhub Python собеседования: t.me/python_job_interview Мобильная разработка: t.me/mobdevelop Golang: t.me/Golang_google React: t.me/react_tg Rust: t.me/rust_code ИИ: t.me/vistehno PHP: t.me/phpshka Android: t.me/android_its Frontend: t.me/front Big Data: t.me/bigdatai МАТЕМАТИКА: t.me/data_math Kubernets: t.me/kubernetc Разработка игр: https://t.me/gamedev Haskell: t.me/haskell_tg Физика: t.me/fizmat 💼 Папка с вакансиями: t.me/addlist/_zyy_jQ_QUsyM2Vi Папка Go разработчика: t.me/addlist/MUtJEeJSxeY2YTFi Папка Python разработчика: t.me/addlist/eEPya-HF6mkxMGIy Папка ML: https://t.me/addlist/2Ls-snqEeytkMDgy Папка FRONTEND: https://t.me/addlist/mzMMG3RPZhY2M2Iy Папка Linux:https://t.me/addlist/w4Doot-XBG4xNzYy 😆ИТ-Мемы: t.me/memes_prog 🇬🇧Английский: t.me/english_forprogrammers 🧠ИИ: t.me/vistehno 🎓954ГБ ОПЕНСОРС КУРСОВ: @courses 📕Ит-книги бесплатно: https://t.me/addlist/BkskQciUW_FhNjEy Сохрани себе, чтобы не потерять!

Почему «Async Django» часто решает не ту проблему Django теперь умеет ASGI и async-views, но автор статьи отмечает: переход на async сам по себе почти ничего не ускоряет. Чтобы получить выгоду, весь код должен быть переписан под асинхронность, а в реальных проектах прирост обычно минимальный. Где async реально нужен? В задачах с большим количеством ожидания: внешние API, WebSockets, стриминг ответов. Там async даёт ощутимую экономию. Но есть нюанс: Django стал «двухрежимным» фреймворком - синхронные и асинхронные части живут рядом, усложняя архитектуру. ORM всё ещё в основном синхронная, и это становится бутылочным горлышком. Поэтому для большинства проектов выгоднее оставить sync Django и вынести тяжёлые операции в фоновые задачи (Celery, RQ). Это проще, надёжнее и предсказуемее. Итог: Async Django - круто с инженерной точки зрения, но бизнес-ценность есть далеко не в каждом сценарии. Для большинства приложений классический Django остаётся лучшим выбором. https://www.loopwerk.io/articles/2025/async-django-why/

👩‍💻 django-cors-headers — Django-приложение для обработки заголовков Cross-Origin Resource Sharing (CORS)! 🌟 Этот инструмент позволяет вашему Django-приложению принимать запросы из браузеров, отправленные с других доменов. Это особенно полезно для API-серверов или приложений, которые обслуживают фронтенд и бэкенд с разных доменов или портов. 🌟 Инструмент позволяет гибко управлять настройками CORS, включая поддержку конкретных методов, заголовков и настроек безопасности. Например, вы можете настроить разрешение только для определённых доменов или включить временный доступ для локальной разработки. Однако важно понимать риски, связанные с CORS, поскольку неправильная конфигурация может открыть доступ к вашим данным для нежелательных источников. 🔐 Лицензия: MIT 🖥 Github @python_job_interview

Профессиональный гайд по работе с ChatGPT (2025) Как использовать ChatGPT не просто как «умного собеседника», а как полноценного помощника для программирования, маркетинга, аналитики и обучения? Мы разберём, какие версии модели существуют, какие плагины открывают новые возможности, как строить промпты так, чтобы получать точные и полезные ответы, и как интегрировать ChatGPT в рабочие процессы. Если у вас нет доступа к chatgpt можете использовать бесплатного бота в телеге, чтобы потестить все техники из статьи или воспользоваться обычной версией с помощью всем известного обхода блокировки. Не будем тянуть время, Поехали! 📌 Гайд

🚀 Django 6.0 — уже в пути! ✨ Главное в Django 6.0 - Content Security Policy (CSP) Новый ContentSecurityPolicyMiddleware, теги csp() и настройки SECURE_CSP / SECURE_CSP_REPORT_ONLY. - Фоновые задачи Декоратор @task и метод enqueue() для простого запуска background jobs. - Template Partials Теги {% partialdef %} и {% partial %} для переиспользуемых фрагментов в шаблонах. - Обновлённое Email API Современный EmailMessage вместо устаревших MIME-классов. - Другие улучшения • В админке — иконки Font Awesome • В auth увеличены итерации PBKDF2 • Улучшения в Postgres, GeoDjango, миграциях и др. 🔄 Изменения без обратной совместимости - Минимальная версия MariaDB — 10.6 - Поддержка Python ≥ 3.12 - DEFAULT_AUTO_FIELD теперь всегда BigAutoField - Удалены устаревшие API и внутренние методы 👉 Подробнее: https://docs.djangoproject.com/en/dev/releases/6.0/ #django #python

🔥 Как я пишу Django views Автор предлагает использовать базовый класс Django View вместо generic class-based views (CBV) или function-based views (FBV). Такой подход даёт простоту и гибкость при работе с HTTP-запросами. Отказ от сложных миксинов и использование понятных вспомогательных методов делает код более читаемым и сопровождаемым, снижая когнитивную нагрузку на разработчика. Ключевые идеи - В Django есть два популярных способа писать views: FBV (функции) и CBV (классы, включая generic views). - Generic CBV часто содержат слишком много "магии": базовые классы, миксины, переопределяемые методы — их трудно держать в голове. - FBV наглядны, но при усложнении логики код превращается в большие конструкции if request.method == .... - Автор выбирает компромисс: использовать базовый класс View. - Код остаётся простым. - Логика neatly разделяется по методам (`get`, post и др.). - Неподдерживаемые методы автоматически возвращают 405 (Method Not Allowed). Пример Вместо функции с if request.method:

class CommentFormView(View):
    def get(self, request, post_id, *args, **kwargs):
        post = get_object_or_404(Post, pk=post_id)
        form = CommentForm()
        return TemplateResponse(request, "form.html", {"form": form, "post": post})

    def post(self, request, post_id, *args, **kwargs):
        post = get_object_or_404(Post, pk=post_id)
        form = CommentForm(data=request.POST)
        if form.is_valid():
            comment = form.save(commit=False)
            comment.post = post
            comment.save()
            return redirect(post)
        return TemplateResponse(request, "form.html", {"form": form, "post": post})

👉 Источник: https://loopwerk.io/articles/2025/django-views/

🖥 rest-filters — фильтрационный бэкенд для Django REST framework Что это: Новый инструмент для фильтрации в DRF, который расширяет возможности стандартного django-filter. Особенности - Использует serializer-поля для разбора и валидации (без Django-форм и виджетов) - Поддержка группировки фильтров для гибкой логики - Constraint system — проверка взаимозависимостей между параметрами - Вложенные фильтры (nested filters) для работы со сложными структурами Последний релиз — v0.6.0 (21 августа 2025) - Возможность указывать группу по умолчанию для всего FilterSet (в том числе глобально) - Поддержка subgroups для более сложных связей между фильтрами - Новый метод FilterSet.get_combinator() для динамического выбора способа объединения фильтров - ⚠️ Breaking change: теперь Entry нельзя создавать без указания группы Почему стоит попробовать Если стандартные фильтры Django REST кажутся ограниченными, rest-filters даёт: - фильтрацию через сериализаторы, - сложные сценарии с группировками и вложенностью, - гибкость и расширяемость. 🔗 Репозиторий: https://github.com/realsuayip/rest-filters

🕸️ Django Tip — ускоряй сложные запросы с помощью `only()` + `defer()` В Django ORM часто делают Model.objects.all(), вытаскивая все поля модели. Но если таблица тяжёлая, это съедает кучу памяти и тормозит. 💡 Лайфхак: загружай только нужные поля:

# Вместо этого
users = User.objects.all()  

# Сделай так
users = User.objects.only("id", "username")  
А если нужно отложить подгрузку дорогих полей (например, JSON или TextField):

users = User.objects.defer("profile_data", "settings_blob")

🟢 Что это даёт ⚡ Сильно ускоряет SQL-запросы (SELECT только нужные столбцы). 📉 Экономит память, так как Django не держит ненужные данные. 🔄 Поля можно подгрузить позже — при первом обращении Django сделает отдельный запрос. 💡 Совет: комбинируй only() и defer() для тонкого контроля — так можно оптимизировать даже очень «тяжёлые» модели без переписывания логики.