Как кэшировать методы чужого Python-клиента

Если библиотечный клиент нельзя менять, его методы можно переопределить с functools.lru_cache. Но кеш тогда включает self в ключ и удерживает экземпляр до вытеснения записи или очистки.

Питоничнее обернуть уже связанный метод после создания объекта: кеш будет отдельным для каждого экземпляра, поэтому состояния клиентов не смешаются. Для множества методов автор перехватывает обращения через __getattribute__, кеширует метод при первом вызове и сохраняет обёртку в __dict__. Если объект создаёт фреймворк, эту механику можно вынести в прокси.

В разборе Caching a lot of methods in Python показано, как вернуть прокси автодополнение через __dir__ и проверки isinstance() через wrapt.ObjectProxy. Для пары методов решение проще: заменить их кешированными прямо у готового объекта.

Как перевести Python-сервер MCP с FastMCP на SDK 2.x

Свежая установка зависимостей сломала сервер автора: в requirements.txt пакет mcp был без ограничения версии, поэтому pip подтянул ветку 2.x, где FastMCP переименовали в MCPServer. Код репозитория не менялся, а прежний импорт перестал работать. Explicit is better than implicit, особенно в файле зависимостей.

Миграция начинается с замены импорта и имени класса. Декораторы @mcp.tool(), @mcp.resource() и тела инструментов в этом проекте остались прежними. Затем стоит закрепить mcp>=2,<3 и отдельно оставить httpx: SDK 2.x больше не устанавливает его как зависимость.

В пошаговом разборе на DEV Community есть проверки синхронных обработчиков, переменных окружения и позиционных аргументов конструктора. Так пакет mcp обновляется внутри репозитория и не откатывается для остальных проектов в системном Python.

Почему миллион чисел в Python занимает 35 МБ

Список из миллиона целых, которые помещаются в 64 бита, занимает в CPython около 35 МБ вместо ожидаемых 8 МБ. Из них 8 МБ уходят на указатели списка, ещё 28 МБ на числа: небольшой объект int весит 28 байт.

В CPython каждое число является объектом. Кроме значения, у него есть счётчик ссылок и указатель на тип. На 64-битной системе эти служебные поля добавляют минимум 16 байт к каждому объекту. Явное лучше неявного, особенно в профиле памяти.

Массив NumPy с типом uint64 хранит значения вместо ссылок на отдельные объекты Python. Поэтому миллион элементов занимает 8 МБ плюс память на импорт библиотеки. В разборе структуры объектов CPython есть замеры и код. Для больших числовых наборов проверьте NumPy до того, как 8 ГБ превратятся в 35 ГБ.

Что ускоряет django-msgspec в Django и где он расходится с json

django-msgspec заменяет компоненты Django и Django REST Framework аналогами на базе msgspec. Его написанные на C кодировщик и декодировщик JSON работают в несколько раз быстрее стандартной библиотеки. В пакете есть JsonResponse, тестовый клиент и json_script, а сериализаторы сессий и парсеры Django REST Framework подключаются через настройки.

Совместимость близка к json, но не полна. Числовые ключи словаря превращаются в строки, большие целые сохраняются. При этом бесконечность кодируется как null, а ключи None и bool вызывают ошибку. Explicit is better than implicit: перед заменой стоит прогнать тесты на реальных данных.

В разборе Адама Джонсона есть примеры настройки для ответов, сессий, dumpdata и loaddata, а также Django REST Framework.

Как collections.deque хранит элементы блоками

У deque два конца, поэтому легко представить узел на каждый объект. В CPython звено списка хранит блок до 64 элементов. Соседние блоки связаны в обе стороны, а индексы указывают на первый и последний элементы.

При append и pop внутри блока меняются индекс и ячейка. Новый блок нужен, лишь когда крайний заполнен; опустевший крайний блок отсоединяется. Поэтому интерпретатор реже выделяет и освобождает память, чем при отдельном узле на элемент, и deque работает быстрее.

В разборе на mathspp.com эта механика собрана в упрощённой Python-реализации для Python 3.15. По коду можно проследить append и pop; левый край устроен симметрично.