Python/ django
по всем вопросам @workakkk @itchannels_telegram - 🔥 все ит каналы @ai_machinelearning_big_data -ML @ArtificialIntelligencedl -AI @datascienceiot - 📚 @pythonlbooks РКН: clck.ru/3FmxmM
Show more📈 Analytical overview of Telegram channel Python/ django
Channel Python/ django (@pythonl) in the Russian language segment is an active participant. Currently, the community unites 58 612 subscribers, ranking 2 183 in the Technologies & Applications category and 10 242 in the Russia region.
📊 Audience metrics and dynamics
Since its creation on невідомо, the project has demonstrated rapid growth, gathering an audience of 58 612 subscribers.
According to the latest data from 06 October, 2026, the channel demonstrates stable activity. Although there has been a change in the number of participants by -331 over the last 30 days and by -19 over the last 24 hours, overall reach remains high.
- Verification status: Not verified
- Engagement rate (ER): The average audience engagement rate is 6.68%. Within the first 24 hours after publication, content typically collects 3.17% reactions from the total number of subscribers.
- Post reach: On average, each post receives 3 916 views. Within the first day, a publication typically gains 1 858 views.
- Reactions and interaction: The audience actively supports content: the average number of reactions per post is 20.
- Thematic interests: Content is focused on key topics such as github, claude, контекст, архитектура, api.
📝 Description and content policy
The author describes the resource as a platform for expressing subjective opinions:
“по всем вопросам @workakkk
@itchannels_telegram - 🔥 все ит каналы
@ai_machinelearning_big_data -ML
@ArtificialIntelligencedl -AI
@datascienceiot - 📚
@pythonlbooks
РКН: clck.ru/3Fm...”
Thanks to the high frequency of updates (latest data received on 07 October, 2026), the channel maintains relevance and a high level of publication reach. Analytics show that the audience actively interacts with content, making it an important point of influence in the Technologies & Applications category.
requirements.txt. Подбирает минимальную подходящую версию пакета, чтобы сократить масштаб изменений.
Запуск из папки проекта:
uvx django-upgrade-report
Отчёт можно сохранить в HTML, Markdown или JSON и подключить к CI. Совместимость оценивается по метаданным пакетов, поэтому тесты проекта всё равно нужны.
https://github.com/derblub/django-upgrade-reportasyncio, ожидание I/O и удержание GIL.
Подключение к процессу по PID:
python3.15 -m profiling.sampling attach 12345
🎙 В Talk Python разработчики рассказывают, как устроен профилировщик и как применять его на практике:
https://talkpython.fm/episodes/show/565/tachyon-python-3.15s-built-in-sampling-profilerllama.cpp
- данные остаются локально
Это не универсальный чат-бот, а узкоспециализированная reasoning-модель. Лицензия — non-commercial.
https://huggingface.co/webAI-Official/TwIL-LM3-Pro
pip install cayu pytest
cayu new myagent
cd myagent
pytest
cayu eval run
https://github.com/cayu-dev/cayure.match()
re.match() никуда не удаляют, но для нового кода его теперь рекомендуют не использовать.
Причина простая: название функции часто сбивает с толку. re.match() проверяет совпадение только с начала строки, хотя по имени это неочевидно.
В Python 3.15 появился более явный вариант:
re.prefixmatch()
Теперь логика выглядит понятнее:
- re.search() — ищет совпадение в любом месте;
- re.prefixmatch() — только с начала строки;
- re.fullmatch() — вся строка должна совпасть полностью.
re.match() получил статус soft deprecated: он остаётся рабочим, без warning и без планов на удаление, но новый код лучше писать без него.
Проверять старое использование можно через Ruff и правило TID251.
Статья: https://hugovk.dev/blog/2026/soft-deprecating-re-match/fastapi-security-headers добавляет к ответам приложения HTTP-заголовки: HSTS, защиту от MIME sniffing, ограничения на встраивание страниц и другие политики браузера. Подключается как ASGI middleware:
app.add_middleware(SecurityHeadersMiddleware)
Есть готовые настройки для JSON API, строгой политики и Swagger UI, чтобы /docs продолжал работать. Заголовки можно настроить под конкретное приложение или переопределить для отдельного маршрута.
GitHub - https://github.com/aletgdev/fastapi-security-headersAGENTS.md, CLAUDE.md, SKILL.md, описания инструментов и конфигурации агентов. Ищет расплывчатые инструкции, циклы без условия остановки и расхождения между описанием инструмента и его схемой.
Работает локально, без вызовов LLM. Его можно запустить перед коммитом или добавить в CI, чтобы новые ошибки в инструкциях попадали на проверку вместе с кодом.
uvx lintlang scan AGENTS.md
https://github.com/hermes-labs-ai/lintlang
uvx pyscn analyze .
Что полезно забрать в свой проект:
* Блокировать в CI новые проблемы, а не сразу весь накопленный техдолг.
* Следить за изменением сложности, а не только за общей оценкой.
* Закрепить допустимые зависимости между модулями проверяемыми правилами.
* Дать агенту запускать анализатор до отправки кода на ревью.
Высокая сложность сама по себе ещё не повод переписывать функцию. Иногда длинная последовательность понятных проверок лучше искусственного дробления.
Статья — https://codescan.dev/blog/ruff-mypy-pytest-and-then-whatobj.x часто вообще не делает lookup по словарю. После прогрева интерпретатор специализирует LOAD_ATTR, а значение читается почти напрямую из inline storage объекта.
Но достаточно выполнить:
`obj.__dict__`
или:
`vars(obj)`
а в некоторых случаях даже:
`copy.copy(obj)`
— и __dict__ материализуется. После этого объект теряет быстрый специализированный путь на оставшееся время жизни.
На CPython 3.14.6 в тесте на M3:
обычный объект → 33.0 ms
после чтения __dict__ → 50.6 ms
В free-threaded сборке разрыв ещё больше:
34.0 ms → 59.4 ms.
Интересная деталь: __slots__ сам по себе почти не ускоряет обычный attribute access. Его преимущество здесь в другом — у объекта нет __dict__, значит его невозможно случайно материализовать и сбить оптимизацию.
Очень неочевидная причина, почему vars() или copy.copy() внутри hot path могут неожиданно ударить по производительности.
https://deadlovelll.github.io/2026-09-05-reading-dict-deoptimizes-attribute-access/