🐍 Django-разработчикам: `DEBUG=True` в проде опаснее, чем кажется.

Это не просто красивые страницы ошибок. При включённом DEBUG приложение может раскрывать stack trace, настройки, пути файлов, middleware, URL-паттерны и другие детали окружения.

Главная рекомендация - fail closed:

DEBUG = False

То есть по умолчанию DEBUG всегда выключен, а включается только локально.

Даже staging, QA и preview-среды, доступные из интернета, лучше запускать с DEBUG=False.

Отдельная ловушка - переменные окружения:

DEBUG = os.environ.get("DEBUG", "False") != "False"

Здесь DEBUG=false или DEBUG=0 могут неожиданно превратиться в True.

Лучше явно парсить boolean или использовать django-environ.

Мелкая настройка, которая однажды может спасти production от очень неприятной утечки.

https://lincolnloop.com/blog/setting-djangos-debug-safely/

#Python #Django #Backend #Security #DevOps

Нечёткий поиск в Django + PostgreSQL можно сделать намного умнее обычного icontains.

В Caktus Group разобрали fuzzy string matching средствами самого PostgreSQL - без отдельного Elasticsearch.

Идея проста: вместо точного совпадения искать строки, похожие друг на друга.

Для этого в PostgreSQL можно использовать:

- pg_trgm
- trigram similarity
- Django TrigramSimilarity
- пороги похожести
- GIN/GiST индексы для ускорения поиска

Например, пользователь вводит имя с опечаткой, переставляет буквы или пишет только часть слова - а приложение всё равно находит нужную запись.

Особенно полезно для поиска по именам, адресам, названиям компаний и любым пользовательским данным, где идеального ввода ждать не стоит.

https://www.caktusgroup.com/blog/2026/08/21/fuzzy-string-matching-django-postgresql/

🔥 Хак в Django: Meta.indexes можно использовать для собственных миграций

Оказывается, models.Index в Django можно превратить почти в универсальную migration-операцию.

Идея:

class CustomMigrationOperation(models.Index):
    def create_sql(self, model, schema_editor, **kwargs):
        ...

    def remove_sql(self, model, schema_editor, **kwargs):
        ...

А затем добавить её прямо в модель:

class Meta:
    indexes = [CustomMigrationOperation()]

После этого makemigrations сам подхватит изменение, а migrate выполнит нужный SQL.

Почему это работает:

Index уже умеет генерировать SQL через create_sql() и remove_sql().

Так можно описывать не только индексы, но и:

triggers
table comments
security labels
другие schema-level настройки

Автор использовал этот приём для PostgreSQL Anonymizer, чтобы правила анонимизации жили рядом с моделью и автоматически попадали в миграции.

Подход довольно hacky, но как способ расширить механизм миграций Django — очень интересный.

https://www.better-simple.com/django/2026/09/02/nifty-feature-use-index-for-custom-migrations/

🔥 Django Q() objects — один из самых полезных инструментов ORM, который многие используют слишком редко

Q() позволяет собирать сложные условия для WHERE, комбинируя их через AND, OR и NOT.

Пример:

Pet.objects.filter(
    Q(last_given_treats__isnull=True)
    | Q(last_given_treats__lte=timezone.now() - timedelta(days=1)),
    treats_needed__gt=F("treats_given"),
)

Особенно полезно для динамических фильтров:

q = Q()

for term in search_term.split():
    q |= Q(name__icontains=term)

Pet.objects.filter(q)

Но есть ещё более важный момент.

При фильтрации через related models два отдельных .filter() могут привести к двум JOIN и неожиданно изменить смысл запроса.

Species.objects.filter(
    pets__name__icontains="meowy"
).filter(
    pets__treats_given=0
)

Это уже может искать одну запись по имени, а другую - по количеству treats.

Если собрать условия в одном .filter() или через Q(), Django использует один JOIN и проверяет условия на одной и той же связанной записи.

Очень полезный приём для сложных QuerySet, динамического поиска и composable business filters.

https://www.better-simple.com/django/2026/09/09/nifty-feature-q-objects/

Вопросы на собеседовании Python Senior: 100 вопросов с ответами (2026)

Вопросы на собеседовании Python Senior с ответами: 100 вопросов и примеры кода — CPython, GIL, asyncio, метаклассы, типизация, производительность, Python 3.14.


https://uproger.com/voprosy-na-sobesedovanii-python-senior/

🐍 Какая зависимость держит ваш Django на старой версии?

django-upgrade-report читает зависимости проекта, проверяет заявленную совместимость на PyPI и составляет план обновления:

- Какие пакеты блокируют переход.
- Что можно обновить заранее.
- Что нужно обновлять одновременно с Django.
- Где потребуется ручная проверка.

Поддерживает lock-файлы uv, Poetry, PDM, Pipenv и requirements.txt. Подбирает минимальную подходящую версию пакета, чтобы сократить масштаб изменений.

Запуск из папки проекта:

uvx django-upgrade-report

Отчёт можно сохранить в HTML, Markdown или JSON и подключить к CI. Совместимость оценивается по метаданным пакетов, поэтому тесты проекта всё равно нужны.

https://github.com/derblub/django-upgrade-report

django-upgrade-report. Показывает, какие зависимости блокируют апгрейд Django и в каком порядке их обновлять.
https://github.com/derblub/django-upgrade-report

🔥 Хочешь быстрее расти в IT? Хватит учиться в одиночку

Окружение решает больше, чем кажется.

Собрал папки и каналы, где можно быстрее влиться в нужное направление, следить за трендами и не вариться в своём пузыре.

AI: t.iss.one/ai_machinelearning_big_data
Python: t.iss.one/pythonl
Linux: t.iss.one/linuxacademiya
Хакинг: t.iss.one/linuxkalii
DevOps: t.iss.one/DevOPSitsec
Docker: https://t.iss.one/+90Z5TAyfuNU5YmRi
Golang: t.iss.one/Golang_google
Rust: t.iss.one/rust_code
C++: t.iss.one/cpluspluc
C#: t.iss.one/csharp_ci
Java: t.iss.one/javatg
JavaScript: t.iss.one/javascriptv
React: t.iss.one/react_tg
Frontend: t.iss.one/front
PHP: t.iss.one/phpshka
Android: t.iss.one/android_its
Мобильная разработка: t.iss.one/mobdevelop
Базы данных: t.iss.one/sqlhub
Data Science: t.iss.one/data_analysis_ml
Big Data: t.iss.one/bigdatai
Математика: t.iss.one/data_math
Физика: t.iss.one/fizmat
Kubernetes: t.iss.one/kubernetc
GameDev: https://t.iss.one/gamedev
Haskell: t.iss.one/haskell_tg

Собеседования и карьера:

DS собеседования: t.iss.one/machinelearning_interview
Python собеседования: t.iss.one/python_job_interview

Папка с вакансиями: t.iss.one/addlist/_zyy_jQ_QUsyM2Vi
Папка Go разработчика: t.iss.one/addlist/MUtJEeJSxeY2YTFi
Папка Python разработчика: t.iss.one/addlist/eEPya-HF6mkxMGIy
Папка ML: https://t.iss.one/addlist/2Ls-snqEeytkMDgy
Папка Frontend: https://t.iss.one/addlist/mzMMG3RPZhY2M2Iy

Полезное сверху:

ИТ-мемы: t.iss.one/memes_prog
Английский для программистов: t.iss.one/english_forprogrammers
ИИ и технологии: t.iss.one/vistehno
954 ГБ open-source курсов: https://t.iss.one/+rKBQEMccAA01MTcy
ИТ-книги бесплатно: https://t.iss.one/addlist/BkskQciUW_FhNjEy

Max Ai: https://max.ru/ai_machinelearning_big_data
Max python: https://max.ru/pythonl
ТЕХНО: https://max.ru/vistehno
Max Go: https://max.ru/Golang_google
Max Linux: https://max.ru/linuxkalii
Devops: https://max.ru/DevOPSitsec
C#: https://max.ru/csharp_ci
C++: https://max.ru/cpluspluc
SQL: https://max.ru/sqlhub
Java: https://max.ru/javatg

Подписывайся на нужные направления и собирай себе ленту, которая реально двигает вперёд.

django-upgrade-report: CLI, который сам скажет, какие зависимости мешают обновить Django и в каком порядке их менять

Обновление Django обычно упирается не в сам фреймворк, а в десяток сторонних пакетов, которые ещё не поддерживают новую версию. Этот инструмент отвечает на два вопроса сразу: что блокирует апгрейд и что обновлять первым.

Работает так. Читает uv.lock, poetry.lock, pdm.lock, Pipfile.lock, requirements*.txt, pyproject.toml или установленное окружение, включая транзитивные зависимости. Затем спрашивает у PyPI, что каждый пакет заявляет о совместимости: классификаторы Framework :: Django и требования к версии Django. Результат раскладывается по статусам: Blocked, Upgrade first, Upgrade together with Django, Check manually и Ready.

Из полезного. Для каждого пакета называется самая старая версия с поддержкой целевого Django, чтобы шаги были маленькими. Если до цели далеко, строит многошаговый путь через LTS или через каждую версию. Проверяет, не потребуется ли более новый Python, умеет работать с монорепозиториями, Wagtail и django CMS. Может печатать команды обновления и конфиги для Renovate и Dependabot, показывает неиспользуемые прямые зависимости и фичи, удалённые из Django, которые ваш код ещё использует. Есть интерактивный TUI, GitHub Action, pre-commit хук и примеры для GitLab CI.

Запуск без установки: uvx django-upgrade-report --target 6.1. Форматы вывода: текст, Markdown, JSON и самодостаточный HTML. Для CI есть флаг --fail-on blocked, который возвращает ненулевой код выхода.

Код остаётся локально, на PyPI уходят только имена и версии пакетов. Нужен Python 3.10 или новее, сам Django ставить не требуется.

Оговорка: отчёт строится по метаданным, которые заявили мейнтейнеры, и не заменяет прогон тестов. Автор советует использовать его в паре с django-upgrade, который переписывает сам код под новые версии. Лицензия MIT.

Репозиторий: https://github.com/derblub/django-upgrade-report

Источник: https://github.com/derblub/django-upgrade-report

Хотите повлиять на Django 6.2? Команда ищет помощь с тестированием и ревью новых возможностей.

Django Steering Council опубликовал список изменений, которые хотелось бы подготовить к релизу.

Среди крупных:

- `CompositeField` – поддержка многоколоночных подзапросов. Здесь нужны именно тесты.
- `DEFAULT_PK_FIELD` – настройка поля первичного ключа по умолчанию, например UUID.
- Перенос моделей между приложениями.

Есть и менее масштабные PR: `QuerySet.executed_queries`, partitioned cookies, поддержка HTTP-метода QUERY и более понятные сообщения отладки CSRF при работе за прокси.

Это кандидаты на включение, а не гарантированный состав Django 6.2. Им ещё нужны проверки и доработка.

В очереди также более 150 идей. Среди тем для обсуждения – таймауты задач, SRI, import maps и разбор URL баз данных и кешей.

Чтобы помочь, необязательно писать новую функцию. Проверка PR на своём проекте, воспроизводимый баг-репорт или аргументированный отзыв тоже двигают релиз вперёд.

https://www.djangoproject.com/weblog/2026/oct/19/quarterly-contributor-outreach/

Django 6.1: загрузка связанных данных по требованию, каскадное удаление силами БД и новая настройка почты.

Релиз вышел 5 августа. Три основных изменения:

1. Новые режимы загрузки полей

FETCH_PEERS при обращении к незагруженному полю получает данные сразу для объектов из того же QuerySet. Это помогает бороться с N+1:

from django.db import models

books = Book.objects.fetch_mode(models.FETCH_PEERS)

for book in books:
    print(book.author.name)

В этом примере Django выполняет два запроса: за книгами и за их авторами.

Режим `FETCH_RAISE` вместо неявного запроса выбрасывает исключение – полезно для обнаружения неожиданных обращений к БД.

2. Удаление на уровне базы

Для ForeignKey.on_delete появились `DB_CASCADE`, `DB_SET_NULL` и `DB_SET_DEFAULT`. Логику выполняет сама БД через SQL ON DELETE.

Нюанс: `DB_CASCADE` не вызывает сигналы `pre_delete` и `post_delete`.

3. Несколько почтовых бэкендов

Настройка `MAILERS` позволяет описывать разные подключения словарём, а при отправке выбирать нужное через using.

Перед обновлением проверьте версии БД: нужны PostgreSQL 15+, MySQL 8.4+, MariaDB 10.11+ или SQLite 3.37+.

https://www.djangoproject.com/weblog/2026/aug/05/django-61-released/

Django закрыл 6 уязвимостей безопасности. Среди них SSRF, утечка паролей и раскрытие пользовательских данных

3 ноября команда Django выпустила экстренные обновления безопасности для трёх веток фреймворка:

- Django 6.1.3
- Django 6.0.10
- Django 5.2.19

Всего исправлено 6 уязвимостей: одна средней и пять низкой степени серьёзности.

Что обнаружили:

1. SSRF через GeoJSON

Злоумышленник мог передать вредоносный URL в поле crs геометрии GeoJSON. GDAL обращался к внешнему ресурсу или читал локальные файлы от имени Django-процесса.

2. SSRF через SpatialReference

Строковые значения, переданные в SpatialReference и связанные GIS-методы, могли заставить GDAL обращаться к URL или читать файлы на сервере.

3. Утечка приватных данных через кеш

UpdateCacheMiddleware и cache_page() могли создавать одинаковые ключи кеша для запросов с отсутствующим и пустым HTTP-заголовком из Vary. В результате один пользователь мог получить закешированный ответ другого.

4. Раскрытие хешей паролей

В Django Admin пользователи с правом только на просмотр могли видеть полные хеши паролей при определённых конфигурациях пользовательских моделей.

5. Исчерпание памяти при загрузке файлов

MultiPartParser мог полностью буферизовать multipart-файлы с Content-Transfer-Encoding: base64, игнорируя ограничение FILE_UPLOAD_MAX_MEMORY_SIZE.

6. Log Injection

Некорректные значения геометрических полей записывались в логи без экранирования управляющих символов. Это позволяло подделывать записи и изменять отображение логов.

Что делать разработчикам?

Обновить Django до исправленной версии своей ветки. Для GIS-приложений также проверить версию GDAL: полноценная защита от проблемы с SpatialReference требует GDAL 3.9 или новее.

Особенно внимательно стоит проверить приложения, принимающие пользовательский GeoJSON, работающие с GIS-данными и использующие кеширование персонализированных ответов.

Исходный отчёт: https://www.djangoproject.com/weblog/2026/nov/03/security-releases/

Одна правка документа перегрузила PostgreSQL. Как в Django переделали кеш

Команда Джонни Метца хранила в Redis готовый список документов для каждого пользователя. Когда крупный клиент изменил одну общую запись, обработчик сбросил кеш тысяч пользователей. Их следующие запросы почти одновременно пошли в PostgreSQL, и API несколько минут работал медленнее.

Кеш разделили. Для пользователя хранят только ID доступных ему документов. Каждый документ лежит в Redis в одном экземпляре, а Django забирает нужные записи пачкой через get_many. Поле can_edit вычисляют при сборке ответа с учётом прав конкретного пользователя. Теперь при переименовании документа достаточно удалить один ключ doc:<id>.

TTL увеличили до семи дней. Ключи удаляют после коммита через transaction.on_commit: если удалить ключ раньше, параллельный запрос может снова положить в кеш старые данные. При промахе читают из primary, чтобы в кеш не попала устаревшая версия с отстающей реплики.

За три месяца внедрения трафик вырос примерно на 40%, средняя задержка упала примерно на 40%, а число запросов к БД в секунду сократилось вдвое. На обычном пике API обслуживает около 1 100 запросов в секунду, доля попаданий в кеш составляет 97%.

https://johnnymetz.com/posts/caching-at-scale-in-django/