Библиотека питониста

🧠 MCP на Python: самый простой пример

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

MCP (Model Context Protocol) решает это, добавляя модели внешние инструменты на Python.

В примере из статьи:
🕒 функция get_current_time() — возвращает текущее время
📅 функция get_current_date() — возвращает текущую дату
🤖 модель через Ollama (llama3.2) может вызывать их по необходимости

Запрос пользователя → модель понимает, нужен ли инструмент → вызывает Python-функцию через MCP → получает результат → формирует ответ

Пример:
«Сколько сейчас времени?»
→ модель вызывает get_current_time()
→ получает 10:35:15
→ отвечает уже человеческим текстом

Чтобы узнать больше о разработке ИИ-агентов приходите на наш курс

📍 Навигация: Вакансии • Задачи • Собесы

Библиотека дата-сайентиста

#буст

🔥 Знакомьтесь с экспертом Proglib.academy: Эмиль Сатаев

Эмиль — эксперт с 8-летним опытом в разработке, который специализируется на внедрении LLM и агентных подходов в реальные коммерческие сервисы. Он точно знает, как проектировать архитектуру так, чтобы ИИ-функции работали стабильно в связке с внешними системами.

🏃‍♀️ Уже 14 мая Эмиль проведет открытый вебинар!

Обсудим самую «больную» тему: «Почему AI-продукты на базе LLM ломаются и как сделать, чтобы работало».

🗓 Когда: 14 мая в 19:00 (Мск)

Почему Эмиля стоит послушать:

🟣 8+ лет в разработке (Backend и Frontend)

Прошел путь от фулстека до Backend Platform Developer в SMIT.Studio.

🟣 Международный исследовательский опыт

Работал исследователем в Институте ИИ НИУ ВШЭ и в Национальном университете Сингапура (NUS).

🟣 Преподаватель-практик

Ведет семинары в НИУ ВШЭ, в том числе по проектированию и разработке агентских систем.

🟣 Мастер интеграции AI в Backend

Его главная суперсила — умение правильно встраивать LLM через API, выстраивать workflow и агентную логику в сложных распределенных системах.

🔗 Зарегистрироваться на вебинар

🚨 Django выпустил срочные security-обновления: 6.0.5 и 5.2.14

Команда Django выпустила новые патч-релизы Django 6.0.5 и Django 5.2.14, закрывающие сразу 3 уязвимости безопасности.

🔹 CVE-2026-5766 — DoS через загрузку файлов в ASGI

Обнаружена возможность обхода лимита FILE_UPLOAD_MAX_MEMORY_SIZE в ASGI-запросах при некорректном или заниженном Content-Length.

Злоумышленник потенциально мог отправить слишком большой файл, который попадал в память сервера, вызывая деградацию сервиса или проблемы с производительностью.

Важно: Django напоминает, что ограничение загрузки файлов нужно настраивать не только в Django, но и на уровне веб-сервера (Nginx, Apache, reverse proxy).

🔹 CVE-2026-35192 — Session Fixation через кешируемые страницы

Проблема затрагивает проекты, где включён:

SESSION_SAVE_EVERY_REQUEST = True

и используются публично кешируемые страницы.

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

🔹 CVE-2026-6907 — риск утечки приватных данных через `Vary: *`

Ошибка в UpdateCacheMiddleware могла привести к тому, что запросы с заголовком:

Vary: *

ошибочно кешировались.

Приватные данные могли случайно попасть в cache и быть отданы другим пользователям.

Какие версии затронуты:
— Django main
— Django 6.0
— Django 5.2

По политике безопасности Django все три проблемы получили уровень Low severity, но это всё ещё security fixes для production, особенно если вы используете ASGI, caching или кастомную работу с sessions.

📍 Навигация: Вакансии • Задачи • Собесы

Библиотека дата-сайентиста

#буст

📦 Dependency version pinning ≠ security patching

Интересный и важный разбор о том, как стоит (и не стоит) управлять версиями зависимостей в Python-проектах.

Если вы — разработчик библиотеки, то:

dependencies = [
  "urllib3>=2",
]

— это нормальная практика для указания совместимости, а не безопасности.

❗ Но изменение на:

"urllib3>=2.6.3"

из-за уязвимости — обычно плохая идея для библиотек.

⚠️ Почему нельзя фиксировать security через version specifiers

Библиотеки:
• должны поддерживать широкий диапазон версий
• отвечают за совместимость, а не за безопасность пользователей
• не должны “жёстко чинить” уязвимости зависимостей

Приложения:
• используют lock-файлы (requirements.txt, uv.lock и т.д.)
• фиксируют конкретные безопасные версии
• отвечают за безопасность своего runtime

💥 Проблема массового эффекта

Если бы все библиотеки начали обновлять зависимости из-за CVE:
• urllib3 → 10,000+ зависимостей
• numpy → ~80,000
• requests → ~70,000
• pandas → ~55,000

👉 одна уязвимость = тысячи релизов ежедневно

Это создало бы постоянный "release storm", который не масштабируется.

Есть исключения:
• если фикс уязвимости требует несовместимого API
• если зависимость больше не поддерживает безопасные версии
• если обновление не ломает обратную совместимость

🔗 Ссылка на статью

📍 Навигация: Вакансии • Задачи • Собесы

Библиотека дата-сайентиста

#буст

Это очень полезный репозиторий с 300+ инженерными статьями от крупных tech-компаний про реальные проблемы масштабирования.

Но читать всё подряд не стоит — лучше по темам. Для старта:
— Netflix / Uber / Slack / Stripe — архитектура и масштабирование,
— Figma / DoorDash / GitHub — поиск и производительность,
— Meta / LinkedIn / Netflix — ML-системы.

Минус: часть статей — немного «инженерный маркетинг», а не чистая практика. Но как источник реальных кейсов — очень сильная подборка.

🔗 Ссылка на ресурс

📍 Навигация: Вакансии • Задачи • Собесы

Библиотека дата-сайентиста

#буст

Библиотека питониста

#развлекалово

🔥 Python 3.14.5 Release Candidate уже доступен — и есть важные изменения

Команда Python выпустила Python 3.14.5rc1 — release candidate пятого maintenance-релиза ветки 3.14. Обновление включает 113+ исправлений багов, улучшений сборки и документации.

Но самое интересное — изменение в работе Garbage Collector (GC).

🔥 Что изменилось

Инкрементальный garbage collector, который использовался в Python 3.14.0–3.14.4, откатили обратно к генерационному GC из Python 3.13.

Причина — многочисленные сообщения о повышенном потреблении памяти в production-средах.

Это важный сигнал для backend-разработчиков, ML/DS-команд и тех, кто запускает Python-сервисы под высокой нагрузкой: изменения в memory management могут существенно влиять на стабильность и стоимость инфраструктуры.

🚀 Ключевые возможности Python 3.14

Ветка 3.14 получила действительно крупные изменения:

✅ PEP 779 — Free-threaded Python
Официальная поддержка Python без GIL — большой шаг к настоящему multi-threading.

✅ PEP 649 — Deferred evaluation of annotations
Аннотации теперь вычисляются лениво, улучшая typing semantics.

✅ PEP 750 — Template strings (t-strings)
Новый механизм кастомной обработки строк, похожий на f-strings.

✅ PEP 734 — Multiple interpreters
Несколько интерпретаторов прямо в standard library.

✅ PEP 784 — `compression.zstd`
Поддержка алгоритма сжатия Zstandard в stdlib.

✅ Experimental JIT Compiler
Для macOS и Windows доступен экспериментальный JIT.

✅ Remote attach в `pdb`
Теперь debugger может подключаться к уже запущенному Python process.

✅ UUID v6–v8
Новые версии UUID и ускоренная генерация старых.

✅ Улучшенные error messages
✅ Цветной CLI для argparse, json, calendar, unittest
✅ Новый интерфейс для инспекции running Python processes

Это preview release, поэтому использовать в production пока не рекомендуется.


🖥 Подробнее

📍 Навигация: Вакансии • Задачи • Собесы

Библиотека питониста

#буст

🐍 Python Internals: в чём разница между `.__getitem__()`, `.__getattr__()`, `.__getattribute__()` и `.__get__()`

Если вы когда-либо работали с Python internals, создавали собственные классы, ORM, прокси-объекты, lazy loading или просто пытались понять, как работает доступ к атрибутам — этот разбор обязателен к прочтению.

На первый взгляд все эти dunder-методы выглядят одинаково: они что-то «получают» (`get`). Но в действительности каждый отвечает за отдельный механизм Python.

1️⃣ .__getitem__()

Этот метод вызывается, когда вы используете квадратные скобки:

obj[key]

Python автоматически превращает это в:

obj.__getitem__(key)

Именно поэтому списки, словари, строки и кастомные контейнеры умеют работать через индекс или ключ.

Например, можно создать класс, который:
• принимает несколько ключей сразу
• ограничивает доступ к данным
• меняет поведение индексации
• реализует собственную логику выборки

2️⃣ .__getattribute__()

Каждый раз, когда вы пишете:

obj.attribute

Python ВСЕГДА сначала вызывает:

obj.__getattribute__("attribute")

Именно этот метод решает:
— является ли объект data descriptor
— есть ли attribute у экземпляра (`instance.__dict__`)
— существует ли non-data descriptor
— есть ли атрибут у класса
— нужно ли запускать fallback-механизм

⚠️ Переопределять .__getattribute__() нужно крайне осторожно — легко сломать доступ ко всем атрибутам объекта.

3️⃣ .__getattr__()

Этот метод вызывается только если Python не нашёл атрибут обычным способом.

Например:

obj.username

Если username не существует, Python попробует:

obj.__getattr__("username")

Это полезно для:
• lazy loading
• динамических атрибутов
• delegation/proxy objects
• ORM-моделей
• API wrappers

Например, можно автоматически брать значения из словаря:

obj.name

вместо:

obj["name"]

4️⃣ .__get__()

Самый недооценённый механизм Python.

Если класс реализует:

__get__()

то он становится descriptor.

Descriptors лежат в основе:
• @property
• bound methods
• classmethod
• staticmethod
• ORM field systems (Django, SQLAlchemy)
• validation frameworks

Python использует descriptors буквально повсюду.

🔥 Порядок поиска атрибута в Python

Когда вызывается:

obj.attribute

Python проверяет:
1. Data descriptor (`__get__ + __set__`)
2. Instance attribute (`obj.__dict__`)
3. Non-data descriptor (`__get__`)
4. Class attribute
5. .__getattr__() как fallback

📍 Навигация: Вакансии • Задачи • Собесы

Библиотека питониста

#буст

🐍 Python Tutorial: практическое руководство по изучению Python

Этот туториал поможет освоить язык от базовых концепций до более продвинутых тем — с примерами, объяснениями и практическим подходом.

📍 Навигация: Вакансии • Задачи • Собесы

Библиотека питониста

#буст