🐍 Telethon: Создаем мощных Telegram-ботов и скрипты автоматизации на Python
Если для работы с Telegram ты до сих пор используешь только стандартные библиотеки для обычных ботов (вроде
Задача:
— Парсить контент, собирать базу пользователей или анализировать сообщения из любых открытых каналов.
— Создавать юзерботов (скрипты, которые работают от твоего личного имени), автоматизирующих ответы в личке или управление группами.
— Переносить и бэкапить медиафайлы, архивы чатов и логов без ограничений Bot API.
Решение:
Мы регистрируем приложение на официальном портале Telegram, получаем ключи
Почему это киллер-фича для автоматизации?
— Полная свобода действий: Скрипт умеет всё то же самое, что и ты в своем смартфоне: вступать в каналы, отправлять реакции, скачивать тяжелые файлы, мониторить сообщения в реальном времени и даже звонить.
— **Асинхронность (
— Удобная работа с медиа: Скачивание картинок, видео или документов из постов реализуется буквально одной строчкой кода.
— Обход жестких лимитов: Хотя у MTProto есть свои ограничения (Flood Wait), они гораздо лояльнее, чем лимиты для стандартных HTTP-ботов.
Как это выглядит в коде?**
Простой пример скрипта, который подключается к аккаунту и автоматически пересылает новые посты из одного канала в другой:
Кому это нужно?
— Разработчикам, создающим сложные системы мониторинга упоминаний брендов или ключевых слов в соцсетях.
— Админам сеток Telegram-каналов для настройки автопостинга, кросспостинга и бэкапа контента.
— Всем, кто хочет автоматизировать рутинные ответы в мессенджере или собрать датасет для обучения нейросети.
Совет: При первом запуске скрипт попросит ввести номер телефона и код подтверждения из Telegram — так создается файл сессии (
🔥 — если за мощные скрипты и работу через MTProto
🤝 — если для всех задач хватает обычного Bot API
➡️ GitHub Ready | #Уроки
Если для работы с Telegram ты до сих пор используешь только стандартные библиотеки для обычных ботов (вроде
aiogram или telebot), ты ограничен правилами Bot API. Ты не можешь читать историю чатов, анализировать активность пользователей в чужих группах или автоматически пересылать посты. Telethon — это мощная асинхронная библиотека на Python, которая работает напрямую через протокол MTProto (как официальные приложения), позволяя автоматизировать абсолютно любые действия от лица обычного пользователя.Задача:
— Парсить контент, собирать базу пользователей или анализировать сообщения из любых открытых каналов.
— Создавать юзерботов (скрипты, которые работают от твоего личного имени), автоматизирующих ответы в личке или управление группами.
— Переносить и бэкапить медиафайлы, архивы чатов и логов без ограничений Bot API.
Решение:
Мы регистрируем приложение на официальном портале Telegram, получаем ключи
api_id/api_hash и пишем асинхронный скрипт, который управляет аккаунтом на чистом Python.Почему это киллер-фича для автоматизации?
— Полная свобода действий: Скрипт умеет всё то же самое, что и ты в своем смартфоне: вступать в каналы, отправлять реакции, скачивать тяжелые файлы, мониторить сообщения в реальном времени и даже звонить.
— **Асинхронность (
asyncio): Библиотека полностью асинхронна из коробки. Это позволяет одновременно следить за сотнями чатов и обрабатывать потоки данных без зависания скрипта.— Удобная работа с медиа: Скачивание картинок, видео или документов из постов реализуется буквально одной строчкой кода.
— Обход жестких лимитов: Хотя у MTProto есть свои ограничения (Flood Wait), они гораздо лояльнее, чем лимиты для стандартных HTTP-ботов.
Как это выглядит в коде?**
Простой пример скрипта, который подключается к аккаунту и автоматически пересылает новые посты из одного канала в другой:
from telethon import TelegramClient, events
api_id = 1234567 # Твой api_id с my.telegram.org
api_hash = 'your_hash_здесь'
client = TelegramClient('my_session', api_id, api_hash)
# Слушаем новые сообщения в определенном канале
@client.on(events.NewMessage(chats='source_channel_username'))
async def handler(event):
# Пересылаем сообщение в свой целевой канал
await client.send_message('my_target_channel', event.message)
print("Скрипт автоматизации запущен...")
client.start()
client.run_until_complete()
Кому это нужно?
— Разработчикам, создающим сложные системы мониторинга упоминаний брендов или ключевых слов в соцсетях.
— Админам сеток Telegram-каналов для настройки автопостинга, кросспостинга и бэкапа контента.
— Всем, кто хочет автоматизировать рутинные ответы в мессенджере или собрать датасет для обучения нейросети.
Совет: При первом запуске скрипт попросит ввести номер телефона и код подтверждения из Telegram — так создается файл сессии (
my_session.session). Береги этот файл и не выкладывай его в открытый доступ (например, на GitHub), так как он заменяет собой пароль и дает полный доступ к твоему аккаунту.🔥 — если за мощные скрипты и работу через MTProto
🤝 — если для всех задач хватает обычного Bot API
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5🤝1
📄 JSON:API: Как раз и навсегда стандартизировать твой REST API
Когда ты пишешь бэкенд на Python или Node.js, перед тобой всегда встает вопрос: в каком формате отдавать данные фронтенду? Один разработчик завернет ответ в
Задача:
— Перестать спорить с командой о структуре JSON-ответов.
— Автоматизировать сложную выборку данных, фильтрацию, пагинацию и загрузку связанных сущностей.
— Уменьшить количество запросов от фронтенда к бэкенду за счет умного связывания ресурсов.
Решение:
Вместо того чтобы придумывать велосипед, ты берешь готовый стандарт. Ответ сервера всегда имеет предсказуемую структуру:
Почему это киллер-фича для архитектуры?
— Решение проблемы N+1 на клиенте: Спецификация поддерживает параметр
— Экономия трафика (Sparse Fieldsets): Клиент может явно указать, какие именно поля ему нужны:
— Стандартизованные ошибки: Формат ошибок жестко прописан. Каждая ошибка содержит понятные ключи:
— Готовые библиотеки: Под JSON:API написаны десятки готовых сериализаторов и ORM-адаптеров для всех языков программирования (например,
Пример структуры ответа (Пост и его автор):
Кому это нужно?
— Командам разработки, где бэкенд и фронтенд пишутся разными людьми, чтобы полностью исключить недопонимания по поводу формата данных.
— Разработчикам сложных SPA/PWA приложений с разветвленной структурой данных и кучей связей между сущностями.
Совет: Если ты используешь FastAPI, ты можешь настроить кастомный
🔥 — если за строгие стандарты и порядок в API
🤝 — если под каждую задачу накидываешь кастомный JSON руками
➡️ GitHub Ready | #Уроки
Когда ты пишешь бэкенд на Python или Node.js, перед тобой всегда встает вопрос: в каком формате отдавать данные фронтенду? Один разработчик завернет ответ в
{"data": [...]}, другой сделает {"results": {}, "status": "ok"}, а третий забудет про пагинацию. В итоге клиентское приложение постоянно ломается, а на согласование JSON-схем уходят часы. JSON:API — это строгая спецификация, которая определяет конкретный формат для запросов и ответов.Задача:
— Перестать спорить с командой о структуре JSON-ответов.
— Автоматизировать сложную выборку данных, фильтрацию, пагинацию и загрузку связанных сущностей.
— Уменьшить количество запросов от фронтенда к бэкенду за счет умного связывания ресурсов.
Решение:
Вместо того чтобы придумывать велосипед, ты берешь готовый стандарт. Ответ сервера всегда имеет предсказуемую структуру:
data для основных ресурсов, included для связанных данных, meta для пагинации и errors для ошибок.Почему это киллер-фича для архитектуры?
— Решение проблемы N+1 на клиенте: Спецификация поддерживает параметр
include. Если фронтенду нужно получить пост и сразу же автора с его комментариями, он просто делает запрос GET /posts/1?include=author,comments. Сервер отдает всё в одном JSON, распределяя связи по своим местам.— Экономия трафика (Sparse Fieldsets): Клиент может явно указать, какие именно поля ему нужны:
GET /users?fields[users]=name,email. Бэкенд не будет вытягивать из базы тяжелые текстовые описания или аватарки, если они сейчас не нужны на экране.— Стандартизованные ошибки: Формат ошибок жестко прописан. Каждая ошибка содержит понятные ключи:
status (HTTP код), title, detail (описание для разработчика) и source (указатель на конкретное поле в запросе, которое вызвало проблему).— Готовые библиотеки: Под JSON:API написаны десятки готовых сериализаторов и ORM-адаптеров для всех языков программирования (например,
marshmallow-jsonapi для Python). Ты просто скармливаешь им модель из базы, а правильный JSON собирается сам.Пример структуры ответа (Пост и его автор):
{
"data": {
"type": "posts",
"id": "1",
"attributes": {
"title": "Docker Compose для новичков"
},
"relationships": {
"author": {
"data": { "type": "users", "id": "42" }
}
}
},
"included": [
{
"type": "users",
"id": "42",
"attributes": {
"name": "Alex",
"role": "DevOps"
}
}
]
}
Кому это нужно?
— Командам разработки, где бэкенд и фронтенд пишутся разными людьми, чтобы полностью исключить недопонимания по поводу формата данных.
— Разработчикам сложных SPA/PWA приложений с разветвленной структурой данных и кучей связей между сущностями.
Совет: Если ты используешь FastAPI, ты можешь настроить кастомный
ResponseClass, который будет автоматически валидировать и оборачивать выходные Pydantic-модели в формат JSON:API. Это позволит сохранить скорость разработки, получив все плюсы строгого стандарта.🔥 — если за строгие стандарты и порядок в API
🤝 — если под каждую задачу накидываешь кастомный JSON руками
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2🔥2
📝 Pydantic V2: Валидация данных в Python на космической скорости
Если ты пишешь бэкенд на Python (особенно на FastAPI), ты точно знаком с Pydantic. Это главная библиотека для парсинга и валидации данных, которая превращает сырой JSON в строгие Python-объекты. Но если в твоем проекте до сих пор используются старые модели первой версии (V1), ты теряешь огромный запас производительности. Вторая версия Pydantic была полностью переписана, и её ядро теперь работает на Rust.
Задача:
— Валидировать огромные объемы входящих данных (API-запросы, логи, конфигурации) без просадки по CPU.
— Избавиться от костылей при очистке и преобразовании полей (например, автоматическое удаление пробелов или приведение строк к нижнему регистру).
— Получить строгую типизацию и предсказуемое поведение моделей при интеграции с базами данных.
Решение:
Переходим на Pydantic V2. За счет того, что вся тяжелая логика проверки типов и разбора строк теперь происходит на уровне скомпилированного кода на Rust, скорость работы выросла в 5–50 раз в зависимости от структуры модели.
Что изменилось и почему это круто?
— **Rust-мотор под капотом (
— Два режима валидации:** Появился метод
— Встроенные модификаторы (Annotated): Больше не нужно писать кастомные валидаторы через
— Разделение на Python и JSON структуры: Метод
Как это выглядит в коде?
Кому это нужно?
— Разработчикам микросервисов, обрабатывающих тысячи запросов в секунду, где важна каждая миллисекунда ответа сервера.
— Дата-инженерам для первичной фильтрации и валидации грязных данных перед их сохранением в СУБД или передачей в аналитические движки (вроде Polars).
Совет: Если ты мигрируешь старый проект с V1 на V2, тебе не обязательно переписывать все файлы разом. Разработчики оставили legacy-модуль. Достаточно изменить импорт с
🔥 — если уже перешел на V2 и кайфуешь от скорости
🤝 — если в проектах до сих пор крутится старый добрый Pydantic V1
➡️ GitHub Ready | #Уроки
Если ты пишешь бэкенд на Python (особенно на FastAPI), ты точно знаком с Pydantic. Это главная библиотека для парсинга и валидации данных, которая превращает сырой JSON в строгие Python-объекты. Но если в твоем проекте до сих пор используются старые модели первой версии (V1), ты теряешь огромный запас производительности. Вторая версия Pydantic была полностью переписана, и её ядро теперь работает на Rust.
Задача:
— Валидировать огромные объемы входящих данных (API-запросы, логи, конфигурации) без просадки по CPU.
— Избавиться от костылей при очистке и преобразовании полей (например, автоматическое удаление пробелов или приведение строк к нижнему регистру).
— Получить строгую типизацию и предсказуемое поведение моделей при интеграции с базами данных.
Решение:
Переходим на Pydantic V2. За счет того, что вся тяжелая логика проверки типов и разбора строк теперь происходит на уровне скомпилированного кода на Rust, скорость работы выросла в 5–50 раз в зависимости от структуры модели.
Что изменилось и почему это круто?
— **Rust-мотор под капотом (
pydantic-core): Библиотека больше не тратит циклы интерпретатора Python на циклы и проверки. Все базовые типы проверяются на максимальной скорости.— Два режима валидации:** Появился метод
model_validate_json(). Он позволяет парсить сырую JSON-строку напрямую, минуя промежуточную стадию перевода в стандартный Python-словарь через json.loads(). Это дает колоссальный прирост производительности на высоконагруженных эндпоинтах.— Встроенные модификаторы (Annotated): Больше не нужно писать кастомные валидаторы через
@validator для тривиальных задач. Очистка строк, ограничение длины массивов или проверка регулярных выражений теперь нативно нанизываются на типы.— Разделение на Python и JSON структуры: Метод
model_dump() заменил старый .dict(), а model_dump_json() пришел на замену .json(). Архитектура стала чище и логичнее.Как это выглядит в коде?
from typing import Annotated
from pydantic import BaseModel, Field, StringConstraints
from pydantic_core import ValidationError
# Ограничиваем строку: убираем пробелы по краям и приводим к нижнему регистру на уровне Rust
UsernameStr = Annotated[
str,
StringConstraints(strip_whitespace=True, to_lower=True, min_length=3)
]
class UserTarget(BaseModel):
id: int
# Использование встроенных проверок Field
username: UsernameStr
balance: float = Field(ge=0.0, default=0.0) # Баланс не может быть отрицательным
# Парсим сырой JSON напрямую на максимальной скорости
json_data = '{"id": 42, "username": " Admin_Sanya ", "balance": 150.50}'
try:
user = UserTarget.model_validate_json(json_data)
print(user.username) # Выведет: "admin_sanya" (пробелы удалены, регистр изменен)
print(user.model_dump()) # Быстрый перевод в dict
except ValidationError as e:
print(e.json())
Кому это нужно?
— Разработчикам микросервисов, обрабатывающих тысячи запросов в секунду, где важна каждая миллисекунда ответа сервера.
— Дата-инженерам для первичной фильтрации и валидации грязных данных перед их сохранением в СУБД или передачей в аналитические движки (вроде Polars).
Совет: Если ты мигрируешь старый проект с V1 на V2, тебе не обязательно переписывать все файлы разом. Разработчики оставили legacy-модуль. Достаточно изменить импорт с
from pydantic import BaseModel на from pydantic.v1 import BaseModel, и старый код продолжит работать в изолированном режиме, пока ты постепенно обновляешь архитектуру приложения.🔥 — если уже перешел на V2 и кайфуешь от скорости
🤝 — если в проектах до сих пор крутится старый добрый Pydantic V1
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3
🐳 Docker Init: Секретная команда, которая сама напишет Dockerfile за тебя
Когда нужно контейнеризировать новый проект на Python, Node.js или Go, процесс всегда начинается одинаково: ты идешь гуглить правильный шаблон
Задача:**
— Быстро и без ошибок контейнеризировать проект с нуля.
— Получить оптимизированные под продакшн конфигурационные файлы без ручного копирования шаблонов.
— Сразу настроить правильное кэширование слоев, безопасного non-root пользователя и
Решение:
Ты просто открываешь терминал в корне своего проекта и пишешь одну команду:
Почему это киллер-фича?
— Умное сканирование: Утилита видит файлы вроде
— Production-Ready конфиги: Сгенерированный
— Полный комплект: Команда создает сразу четыре файла:
— Минимум вопросов: Тебе нужно лишь указать порт, на котором крутится приложение, и команду для старта (например,
Как это выглядит на практике?
Для обычного FastAPI-приложения
— Создание изолированного виртуального окружения.
— Монтирование кэша (
— Переключение на системного пользователя
Кому это нужно?
— Разработчикам, которые часто создают новые микросервисы и пет-проекты и хотят тратить время на код, а не на написание инфраструктурных конфигов.
— Тем, кто только знакомится с Docker и боится ошибиться в синтаксисе манифестов.
Совет: Перед запуском команды убедись, что в корне проекта лежат файлы зависимостей (например,
🔥 — если уже используешь встроенные утилиты Docker
🤝 — если по старинке копируешь Dockerfile из старых проектов
➡️ GitHub Ready | #Уроки
Когда нужно контейнеризировать новый проект на Python, Node.js или Go, процесс всегда начинается одинаково: ты идешь гуглить правильный шаблон
Dockerfile, вспоминаешь, как правильно прокидывать зависимости, копировать файлы и настраивать docker-compose.yml. В итоге тратится время на рутину. Но начиная с версии Docker Desktop 4.18 (и в актуальном CLI 2026 года), встроена крутейшая команда — **docker init, которая делает всю эту работу за секунды.Задача:**
— Быстро и без ошибок контейнеризировать проект с нуля.
— Получить оптимизированные под продакшн конфигурационные файлы без ручного копирования шаблонов.
— Сразу настроить правильное кэширование слоев, безопасного non-root пользователя и
.dockerignore.Решение:
Ты просто открываешь терминал в корне своего проекта и пишешь одну команду:
docker init. Скрипт сам проанализирует исходный код, поймет язык программирования и запустит интерактивный конфигуратор.Почему это киллер-фича?
— Умное сканирование: Утилита видит файлы вроде
requirements.txt, package.json или go.mod. Она сама определяет версию языка и предлагает оптимальный базовый образ.— Production-Ready конфиги: Сгенерированный
Dockerfile — это не просто три строчки кода. Он сразу разбит на этапы (multi-stage build), содержит очистку кэша менеджеров пакетов и не запускает приложение от имени root (что критично для безопасности).— Полный комплект: Команда создает сразу четыре файла:
Dockerfile, docker-compose.yml, .dockerignore и файл README.Docker.md с инструкциями по запуску конкретно для твоего стека.— Минимум вопросов: Тебе нужно лишь указать порт, на котором крутится приложение, и команду для старта (например,
uvicorn main:app --host 0.0.0.0).Как это выглядит на практике?
Для обычного FastAPI-приложения
docker init создаст структуру, где в Dockerfile будут автоматически прописаны:— Создание изолированного виртуального окружения.
— Монтирование кэша (
--mount=type=cache), чтобы при повторной сборке и изменении одной строчки кода pip не скачивал все библиотеки заново.— Переключение на системного пользователя
uid=10001 для безопасного выполнения внутри контейнера.Кому это нужно?
— Разработчикам, которые часто создают новые микросервисы и пет-проекты и хотят тратить время на код, а не на написание инфраструктурных конфигов.
— Тем, кто только знакомится с Docker и боится ошибиться в синтаксисе манифестов.
Совет: Перед запуском команды убедись, что в корне проекта лежат файлы зависимостей (например,
pyproject.toml или requirements.txt). Если проект будет абсолютно пустым, docker init не сможет автоматически определить стек и предложит выбрать его вручную из списка общих шаблонов.🔥 — если уже используешь встроенные утилиты Docker
🤝 — если по старинке копируешь Dockerfile из старых проектов
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5🤝1
🐳 FastAPI + Lifespan: Правильный способ управлять запуском и остановкой приложения
Когда ты пишешь бэкенд на Python с использованием FastAPI, тебе часто нужно выполнить какой-то код при старте сервера (например, подключиться к базе данных, прогреть кэш в Redis или инициализировать клиента для Telegram-бота через Telethon) и аккуратно закрыть эти соединения при остановке приложения. Раньше для этого использовались декораторы
Задача:
— Инициализировать тяжелые ресурсы (пулы подключений, клиенты API) строго в момент старта сервера.
— Гарантировать безопасное закрытие всех коннектов при выключении приложения, чтобы не терять данные и не вешать сокеты.
— Использовать единую, чистую асинхронную логику вместо разрозненных функций.
Решение:
Мы пишем специальную асинхронную функцию-контекстный менеджер с использованием декоратора
Почему это киллер-фича?
— Единая логика: Весь жизненный цикл приложения собран в одном месте. Тебе не нужно искать по разным файлам, где создается подключение, а где оно закрывается.
— Безопасная обработка ошибок: Если на этапе старта (до
— Удобство для тестирования: Передавая кастомный lifespan в тестовый клиент
— Поддержка State: Всё, что ты запишешь в словарь контекста через
Как это выглядит в коде?
Кому это нужно?
— Разработчикам высоконагруженных API, где критически важно не плодить лишние коннекты к СУБД на каждый чих, а использовать один глобальный пул.
— Всем, кто переходит на современные версии FastAPI и хочет писать чистый, поддерживаемый асинхронный код.
Совет: Если твое приложение использует много независимых сервисов (база, очереди, микросервисы), ты можешь разбивать логику на несколько контекстных менеджеров и вкладывать их друг в друга или использовать утилиты вроде
🔥 — если уже переписал свои проекты на lifespan
🤝 — если по старинке используешь on_event или инициализируешь всё в глобальной области
➡️ GitHub Ready | #Уроки
Когда ты пишешь бэкенд на Python с использованием FastAPI, тебе часто нужно выполнить какой-то код при старте сервера (например, подключиться к базе данных, прогреть кэш в Redis или инициализировать клиента для Telegram-бота через Telethon) и аккуратно закрыть эти соединения при остановке приложения. Раньше для этого использовались декораторы
@app.on_event("startup") и "shutdown", но они уже официально устарели (deprecated). Современный и безопасный стандарт — это Lifespan-контексты.Задача:
— Инициализировать тяжелые ресурсы (пулы подключений, клиенты API) строго в момент старта сервера.
— Гарантировать безопасное закрытие всех коннектов при выключении приложения, чтобы не терять данные и не вешать сокеты.
— Использовать единую, чистую асинхронную логику вместо разрозненных функций.
Решение:
Мы пишем специальную асинхронную функцию-контекстный менеджер с использованием декоратора
@asynccontextmanager. Весь код до ключевого слова yield выполнится при запуске, а код после yield — перед самым выключением сервера.Почему это киллер-фича?
— Единая логика: Весь жизненный цикл приложения собран в одном месте. Тебе не нужно искать по разным файлам, где создается подключение, а где оно закрывается.
— Безопасная обработка ошибок: Если на этапе старта (до
yield) что-то пойдет не так (например, база данных недоступна), FastAPI сразу остановит запуск и выдаст ошибку. Спецификация гарантирует, что приложение не поднимется в "сломанном" состоянии.— Удобство для тестирования: Передавая кастомный lifespan в тестовый клиент
TestClient, можно легко подменять реальные подключения на моки (mock-объекты) для тестов, сохраняя ту же логику инициализации.— Поддержка State: Всё, что ты запишешь в словарь контекста через
yield {"client": client}, автоматически станет доступно во всех твоих роутах (эндпоинтах) через объект request.state.Как это выглядит в коде?
from contextlib import asynccontextmanager
from fastapi import FastAPI, Request
# 1. Создаем lifespan-контекст
@asynccontextmanager
async def lifespan(app: FastAPI):
# --- Секция STARTUP ---
# Код здесь выполняется ДО того, как приложение начнет принимать запросы
print("Подключаемся к базе данных и Redis...")
db_pool = "Тут реальный пул подключений"
# Передаем ресурсы в state приложения, чтобы использовать их в роутах
yield {"db": db_pool}
# --- Секция SHUTDOWN ---
# Код здесь выполняется ПЕРЕД полной остановкой сервера
print("Закрываем все соединения и сохраняем логи...")
# Очистка ресурсов: db_pool.close()
# 2. Передаем lifespan в экземпляр FastAPI
app = FastAPI(lifespan=lifespan)
# 3. Используем ресурсы в эндпоинтах
@app.get("/items")
async def get_items(request: Request):
# Достаем наш пул из объекта request.state
database = request.state.db
return {"status": "success", "db_info": str(database)}
Кому это нужно?
— Разработчикам высоконагруженных API, где критически важно не плодить лишние коннекты к СУБД на каждый чих, а использовать один глобальный пул.
— Всем, кто переходит на современные версии FastAPI и хочет писать чистый, поддерживаемый асинхронный код.
Совет: Если твое приложение использует много независимых сервисов (база, очереди, микросервисы), ты можешь разбивать логику на несколько контекстных менеджеров и вкладывать их друг в друга или использовать утилиты вроде
contextlib.ExitStack, чтобы не превращать один lifespan-файл в бесконечную простыню кода.🔥 — если уже переписал свои проекты на lifespan
🤝 — если по старинке используешь on_event или инициализируешь всё в глобальной области
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2
🔒 Poetry: Наводим идеальный порядок в зависимостях Python-проектов
Каждый, кто хоть раз писал более-менее крупный скрипт на Python, сталкивался с болью управления зависимостями. Классический
Задача:
— Изолировать зависимости каждого проекта без ручного создания папок
— Гарантировать, что проект развернется на продакшене с точно такими же версиями библиотек, как и на компьютере разработчика.
— Легко разделять пакеты для разработки (например,
Решение:
Poetry отказывается от кучи разрозненных конфигов и переносит всё управление в один стандартизированный файл —
Почему это маст-хэв для Python-разработчика?
— **Файл блокировки (
— Умное разрешение конфликтов: Если две разные библиотеки требуют одну и ту же утилиту, но разных версий, Poetry не даст молча перезаписать пакет (как это делает
— Удобное разделение окружений (Dependency Groups): Можно одной командой добавить пакет исключительно для тестов или линтинга:
— Публикация в один клик: Если ты пишешь свою библиотеку, Poetry позволяет собрать её и загрузить в PyPI всего парой команд:
Основные команды, которые заменят тебе старый подход:
—
—
—
—
Кому это нужно?
— Разработчикам, которые устали вручную чистить
— Командам, которым важна стопроцентная воспроизводимость окружения на компьютерах разных разработчиков и CI/CD пайплайнах.
Совет: Чтобы виртуальное окружение создавалось прямо в папке твоего проекта (в привычной директории
🔥 — если давно перешел на Poetry и забыл про pip
🤝 — если старого доброго requirements.txt до сих пор хватает
➡️ GitHub Ready | #Уроки
Каждый, кто хоть раз писал более-менее крупный скрипт на Python, сталкивался с болью управления зависимостями. Классический
requirements.txt постоянно разрастается, в него попадают лишние подзависимости (транзитивные пакеты), а при попытке развернуть проект на другом сервере всё ломается из-за конфликта версий. Poetry — это современный инструмент, который берет на себя управление виртуальными окружениями, пакетами и сборкой, заменяя собой pip, virtualenv и setup.py разом.Задача:
— Изолировать зависимости каждого проекта без ручного создания папок
.venv.— Гарантировать, что проект развернется на продакшене с точно такими же версиями библиотек, как и на компьютере разработчика.
— Легко разделять пакеты для разработки (например,
pytest, black, dive) и для продакшна (FastAPI, Pydantic).Решение:
Poetry отказывается от кучи разрозненных конфигов и переносит всё управление в один стандартизированный файл —
pyproject.toml. Он автоматически создает виртуальное окружение и жестко контролирует дерево зависимостей.Почему это маст-хэв для Python-разработчика?
— **Файл блокировки (
poetry.lock):** Когда ты устанавливаешь библиотеку, Poetry записывает в этот файл точные версии всех скачанных подпакетов и их хэш-суммы. При деплое команда poetry install поставит именно эти проверенные версии, что полностью исключает ситуацию «у меня локально всё работает, а на сервере упало».— Умное разрешение конфликтов: Если две разные библиотеки требуют одну и ту же утилиту, но разных версий, Poetry не даст молча перезаписать пакет (как это делает
pip), а проведет глубокий анализ дерева зависимостей и выдаст четкую ошибку или найдет компромиссную версию.— Удобное разделение окружений (Dependency Groups): Можно одной командой добавить пакет исключительно для тестов или линтинга:
poetry add pytest --group dev. При сборке продакшн-образа в Docker эти тяжелые библиотеки можно просто проигнорировать ключом --without dev.— Публикация в один клик: Если ты пишешь свою библиотеку, Poetry позволяет собрать её и загрузить в PyPI всего парой команд:
poetry build и poetry publish.Основные команды, которые заменят тебе старый подход:
—
poetry init — интерактивно создает правильный pyproject.toml в существующем проекте.—
poetry add fastapi — скачивает библиотеку, обновляет конфиг и фиксирует изменения в lock-файле.—
poetry run python main.py — запускает твой скрипт прямо внутри изолированного виртуального окружения без необходимости предварительно писать source .venv/bin/activate.—
poetry shell — активирует виртуальное окружение в текущей сессии терминала.Кому это нужно?
— Разработчикам, которые устали вручную чистить
requirements.txt от «мусорных» зависимостей после удаления крупных библиотек.— Командам, которым важна стопроцентная воспроизводимость окружения на компьютерах разных разработчиков и CI/CD пайплайнах.
Совет: Чтобы виртуальное окружение создавалось прямо в папке твоего проекта (в привычной директории
.venv), а не в глобальном кэше системы, сразу после установки Poetry выполни команду: poetry config virtualenvs.in-project true. Это сильно упростит интеграцию с VS Code или PyCharm и позволит Docker-контейнерам легче подхватывать окружение.🔥 — если давно перешел на Poetry и забыл про pip
🤝 — если старого доброго requirements.txt до сих пор хватает
Please open Telegram to view this post
VIEW IN TELEGRAM
🤝3❤1
LSP Enforcement Kit for Claude Code
Механизм принудительного использования LSP-навигации в Claude Code: 6 хуков + 1 трекер состояния, которые блокируют неэффективные поиски через Grep и направляют Claude к использованию LSP-инструментов для навигации по коду.
Поддерживаются MCP-серверы cclsp и Serena LSP. По словам автора, в тестах это дало примерно 73% экономии токенов.
Cсылка на GitHub
Механизм принудительного использования LSP-навигации в Claude Code: 6 хуков + 1 трекер состояния, которые блокируют неэффективные поиски через Grep и направляют Claude к использованию LSP-инструментов для навигации по коду.
Поддерживаются MCP-серверы cclsp и Serena LSP. По словам автора, в тестах это дало примерно 73% экономии токенов.
Cсылка на GitHub
👍2
This media is not supported in your browser
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
Руководитель группы продукта «Поиск и Рекомендации» Яндекс Маркета Любовь Горбунова считает, что необходимость в предельно точных формулировках снижается: нейросеть все лучше понимает запросы и в перспективе с ней можно будет общаться как с консультантом в магазине — в свободной форме и с уточнениями по ходу диалога.
Еще один тренд — использование ИИ вместе с VR/AR-технологиями. Уже сейчас такие решения улучшают сценарии виртуальной примерки одежды. А в будущем подход может распространиться и на другие категории, например, на «примерку» мебели в интерьере.
Please open Telegram to view this post
VIEW IN TELEGRAM
👎3
В новом исследовании изучили Spotify и выяснили, что 93% нейротреков не набирают даже 1000 прослушиваний.
Авторы называют это music slop. Тысячи композиций заливают пачками в разные жанры, надеясь случайно попасть в рекомендации. Дистрибьюторы почти этому не мешают, а детекторы пока легко обходятся.
А как часто вам попадается в реках нейрохрючево?
• Источник
Please open Telegram to view this post
VIEW IN TELEGRAM
😁7❤1
Dir2txt — инструмент командной строки, который позволяет быстро экспортировать структуру и содержимое директории в файлы форматов .txt или .json.👉 Главная цель тулзы — помощь в структурировании кода для интеграции с AI-пайплайнами, такими как GPT-агенты и Retrieval-Augmented Generation.
Клик
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
🐍 FastAPI BackgroundTasks: Как запускать тяжелый код, не заставляя пользователя ждать
Когда пользователь нажимает кнопку «Зарегистрироваться» или «Скачать отчет», твой бэкенд на FastAPI должен среагировать мгновенно. Если внутри этого запроса ты начнешь отправлять приветственное письмо через SMTP, генерировать тяжелый PDF-документ или парсить данные через Telethon, пользователь будет уныло смотреть на крутящийся спиннер несколько секунд. BackgroundTasks — это встроенный в FastAPI инструмент, который позволяет моментально вернуть ответ «Успешно», а тяжелую задачу незаметно докрутить в фоне.
Задача:
— Разгрузить основные эндпоинты API от долгих, не связанных с мгновенным ответом операций.
— Минимизировать время ожидания ответа (TTFB) для клиентов.
— Реализовать простую фоновую обработку без развертывания тяжелых очередей задач.
Решение:
Мы просто добавляем в параметры функции эндпоинта объект
Почему это идеальное быстрое решение?
— Из коробки: Тебе не нужно устанавливать, настраивать и оплачивать Celery, Redis или RabbitMQ. Всё работает на стандартных возможностях Python и Starlette.
— Не блокирует асинхронность: Если ты передаешь асинхронную функцию (
— Доступ к контексту: Фоновые задачи запускаются *после* того, как ответ уже ушел пользователю, но в рамках того же процесса. Они имеют доступ к тем же пулам баз данных или настройкам приложения.
— Чистый код: Логика контроллера остается легковесной — ты просто фиксируешь факт запроса и делегируешь работу дальше.
Как это выглядит в коде?
Кому это нужно?
— Разработчикам микросервисов и ботов, где нужно быстро подтвердить прием команды, а саму обработку (парсинг, отправку уведомлений в сетку каналов) сделать на секунду позже.
— Всем, у кого в проекте есть задачи на 2–10 секунд, ради которых городить полноценный стек Celery + Redis пока объективно рано (оверинжиниринг).
Совет: Помни, что встроенные
🔥 — если разгружаешь эндпоинты через фоновые задачи
🤝 — если пользователь честно ждет, пока скрипт отработает до конца
Когда пользователь нажимает кнопку «Зарегистрироваться» или «Скачать отчет», твой бэкенд на FastAPI должен среагировать мгновенно. Если внутри этого запроса ты начнешь отправлять приветственное письмо через SMTP, генерировать тяжелый PDF-документ или парсить данные через Telethon, пользователь будет уныло смотреть на крутящийся спиннер несколько секунд. BackgroundTasks — это встроенный в FastAPI инструмент, который позволяет моментально вернуть ответ «Успешно», а тяжелую задачу незаметно докрутить в фоне.
Задача:
— Разгрузить основные эндпоинты API от долгих, не связанных с мгновенным ответом операций.
— Минимизировать время ожидания ответа (TTFB) для клиентов.
— Реализовать простую фоновую обработку без развертывания тяжелых очередей задач.
Решение:
Мы просто добавляем в параметры функции эндпоинта объект
BackgroundTasks от самого FastAPI и перекидываем туда нашу тяжелую функцию вместе с нужными аргументами через метод .add_task().Почему это идеальное быстрое решение?
— Из коробки: Тебе не нужно устанавливать, настраивать и оплачивать Celery, Redis или RabbitMQ. Всё работает на стандартных возможностях Python и Starlette.
— Не блокирует асинхронность: Если ты передаешь асинхронную функцию (
async def), FastAPI запустит её в текущем цикле событий (event loop). Если передаешь обычную функцию (def), фреймворк сам отправит её в отдельный поток (thread pool), чтобы она не тормозила остальное приложение.— Доступ к контексту: Фоновые задачи запускаются *после* того, как ответ уже ушел пользователю, но в рамках того же процесса. Они имеют доступ к тем же пулам баз данных или настройкам приложения.
— Чистый код: Логика контроллера остается легковесной — ты просто фиксируешь факт запроса и делегируешь работу дальше.
Как это выглядит в коде?
import time
from fastapi import FastAPI, BackgroundTasks
app = FastAPI()
# Тяжелая функция (например, долгая запись логов в базу или отправка вебхука)
def send_system_notification(email: str, message: str):
time.sleep(5) # Имитируем тяжелую работу на 5 секунд
print(self_email := f"Email sent to {email}: {message}")
@app.post("/subscribe")
async def subscribe_user(email: str, background_tasks: BackgroundTasks):
# Логика быстрой валидации или сохранения в базу данных здесь...
# Ставим задачу в фоновую очередь FastAPI
background_tasks.add_task(send_system_notification, email, message="Welcome to our platform!")
# Пользователь получает этот ответ МГНОВЕННО, не дожидаясь 5 секунд
return {"status": "accepted", "message": "Subscription processing started"}
Кому это нужно?
— Разработчикам микросервисов и ботов, где нужно быстро подтвердить прием команды, а саму обработку (парсинг, отправку уведомлений в сетку каналов) сделать на секунду позже.
— Всем, у кого в проекте есть задачи на 2–10 секунд, ради которых городить полноценный стек Celery + Redis пока объективно рано (оверинжиниринг).
Совет: Помни, что встроенные
BackgroundTasks живут в оперативной памяти твоего запущенного Python-процесса. Если сервер внезапно упадет или перезагрузится прямо в момент выполнения фоновой задачи, она сотрется и не повторится автоматически. Если тебе нужна гарантированная доставка, строгая очередность и сложная логика повторов (retries), тогда уже стоит смотреть в сторону полноценных брокеров вроде TaskIQ или Celery.🔥 — если разгружаешь эндпоинты через фоновые задачи
🤝 — если пользователь честно ждет, пока скрипт отработает до конца