uz
Feedback
Django Python

Django Python

Kanalga Telegram’da o‘tish
6 696
Obunachilar
-624 soatlar
-227 kunlar
-8130 kunlar
Postlar arxiv
🐍 Python Roadmap 2026: наконец-то полноценная актуальная карта изучения Python, а не список ссылок «разберись сам» На GitHub
🐍 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 в 2026 - уже не просто «первый язык программирования». Это инструмент, с которым можно автоматизировать задачи, писать скрипты, собирать проекты, работать с данными, делать ботов и использовать ИИ как ускоритель разработки. Но есть проблема: большинство новичков учат Python кусками. Немного синтаксиса, пару задачек, немного теории - и потом ступор: «а что с этим делать дальше?» Этот курс сделан иначе. Здесь упор на реальную практику: вы не просто смотрите уроки, а постепенно учитесь писать код, разбирать ошибки, собирать рабочие решения и понимать, как Python применяется в нормальных задачах. Что внутри: - Python с нуля понятным языком - практика вместо бесконечной сухой теории - реальные задачи и проекты - автоматизация рутины - работа с файлами, данными и API - понятная логика программирования - современный подход к разработке с ИИ - отдельный акцент на вайбкодинг Вайбкодинг -это умение правильно ставить задачу, проверять код, понимать результат и ускорять работу без слепого копирования. В 2026 году это уже не бонус, а нормальный навык разработчика. Сегодня скидка 60 процентов: https://stepik.org/course/288218/info

⚡️ Вы слышали про Rust. Знаете, что он быстрый, безопасный и что за ним будущее. Осталось одно: сесть и выучить. Этот курс со
⚡️ Вы слышали про Rust. Знаете, что он быстрый, безопасный и что за ним будущее. Осталось одно: сесть и выучить. Этот курс со Stepik- кратчайший путь от «знаю что такое Rust» до «пишу на нём». 6 модулей, 50 уроков, 143 теста. Ownership, borrowing, traits, async, Tokio, Axum, макросы, WASM — всё разложено по полочкам и закреплено практикой. Никакого видео на 40 минут ради одной мысли. Подробный текст, много кода, реальные задачи после каждого урока. На выходе — портфолио из 10+ проектов: от CLI-утилит до REST API с базой данных. 48 часов действует скидка 55 процентов: stepik.org/course/269250

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

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

✔️ Лови полезный 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 ради г
🖥 Большинство “парсеров” умирают через 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 выкатили A
🚀 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 - навык, который отличает нович
🖥 На Stepik вышел курс, который учит работать с Docker на реальных проектах. Владение Docker - навык, который отличает новичка от профи, Сегодня почти всё разворачивается в контейнерах. Если ты не умеешь работать с Docker, ты медленнее, зависим от чужих настроек и постоянно ловишь баги «у меня локально работает». • как упаковывать проекты в контейнеры • как поднимать целые системы за минуты • как избегать типичных ошибок в продакшене • как делать стабильные и повторяемые окружения •в нем разобраны все возможные ошибки Только практика и реальные кейсы от авторов Docker Академии- с нуля до уверенного уровня. 🎁 Скидка 40 процентов действует 48 часов 👉 Записывайся и сделай Docker своим настоящим рабочим инструментом.

🖥 FastAPI для клиента: как должны выглядеть API-клиенты в Python Python-сообщество отлично научилось делать API-серверы. Fas
🖥 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: как сделать правильно В статье рассматривается, как настроить базовую (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, и это одно из самых насыщенных обновлений за последнее
🖥 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 наконец получает встроенный
📌 Первые впечатления от системы фоновых задач в 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-проекта требует продуманной архитектуры.
🖥 Как организовать архитектуру большого Python-проекта? Разработка крупного Python-проекта требует продуманной архитектуры. Правильная структура кода упрощает развитие, тестирование и поддержку приложения. В этой статье мы рассмотрим ключевые принципы архитектурной организации для разных типов проектов - веб-приложений, библиотек, микросервисов и систем обработки данных. Обсудим разделение системы на слои (domain, service, infrastructure), использование популярных шаблонов проектирования (Dependency Injection, Repository, Facade), организацию кода по модулям и пакетам, примеры структуры каталогов, работу с зависимостями и конфигурацией (Pydantic, dotenv), логгирование и мониторинг, обеспечение тестируемости, поддержку расширяемости и модульности. Также приведем примеры кода и структуры каталогов, а в конце – общие советы и распространенные ошибки, которых следует избегать. https://uproger.com/kak-organizovat-arhitekturu-bolshogo-python-proekta/

🚀 django-keel - мощный стартовый шаблон для Django-проектов 💡 Что это такое Готовый современный каркас для Django-приложени
🚀 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 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-cors-headers — Django-приложение для обработки заголовков Cross-Origin Resource Sharing (CORS)! 🌟 Этот инструмент позволяет вашему Django-приложению принимать запросы из браузеров, отправленные с других доменов. Это особенно полезно для API-серверов или приложений, которые обслуживают фронтенд и бэкенд с разных доменов или портов. 🌟 Инструмент позволяет гибко управлять настройками CORS, включая поддержку конкретных методов, заголовков и настроек безопасности. Например, вы можете настроить разрешение только для определённых доменов или включить временный доступ для локальной разработки. Однако важно понимать риски, связанные с CORS, поскольку неправильная конфигурация может открыть доступ к вашим данным для нежелательных источников. 🔐 Лицензия: MIT 🖥 Github @python_job_interview