Pyinstrument - профилировщик Python, который показывает, где код реально тормозит 👀

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

Что умеет:

- поддерживает Python 3.8+
- ставится обычным pip install pyinstrument
- строит интерактивные HTML-профили
- показывает выполнение в timeline mode
- интегрируется с Django через middleware
- работает с FastAPI
- автоматически подстраивает точность отображения времени под интервал профилирования

Удобная штука, когда нужно понять не «какая функция кажется подозрительной», а где программа действительно теряет время.

Для Python-проектов это один из тех инструментов, которые лучше подключить до того, как оптимизация превращается в гадание по логам.

https://github.com/joerick/pyinstrument

🐍 Python Pop Quiz: что окажется внутри `silly_dict`?

Вопрос звучит просто, но тут ловушка в том, как Python работает с ключами словаря.

Варианты:

A) {"py": "amazing"}
B) {"py": 10}
C) {"py": "amazing", <__main__.MyClass object at ...>: 10}
D) None of the above

Суть в том, что ключи в dict сравниваются не по тому, как они выглядят в коде, а через __hash__ и __eq__.

Если объект пользовательского класса имеет такой же хеш, как строка "py", и при сравнении считается равным этой строке, то Python решит: это один и тот же ключ.

В таком случае новое значение просто перезапишет старое.

Ответ: B) `{"py": 10}`

Маленький пример, но отлично показывает важную вещь: в Python ключ словаря - это не “текстовое имя”, а объект с правилами хеширования и сравнения.

🐍 Python Roadmap 2026: наконец-то полноценная актуальная карта изучения Python, а не список ссылок «разберись сам»

На GitHub выложили большой русскоязычный роадмап по Python на 2026 год - от первых скриптов до уровня Middle+/Senior.

Маршрут собран под современный Python:

- Python 3.13+
- free-threaded mode без GIL
- JIT
- uv вместо боли с pip/venv/poetry
- ruff, pyright, pytest, hypothesis
- async-first подход
- типизация
- CPython внутри
- web, базы, ML/AI, DevOps и архитектура

В роадмапе есть нормальная последовательность: сначала окружение и база, потом идиомы, ООП, типы, стандартная библиотека, асинхронность, тестирование, внутренности CPython, web, базы данных, AI-направление, продакшн и архитектура.

Отдельный плюс - практический формат. На каждом этапе есть задачи, чеклисты, примеры кода и бесплатные ресурсы. То есть это не мотивационная простыня, а маршрут, по которому реально можно идти несколько месяцев и видеть прогресс.

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

Python в 2026 году - это tooling, типы, async, инфраструктура, AI и продакшн-дисциплина. И этот роадмап как раз про такой Python.

https://github.com/justxor/pythonroamap2026

Агенты наконец-то получают нормальную память

agentmemory - это локальный слой памяти для AI coding agents, который решает одну из самых раздражающих проблем: каждый новый сеанс агент снова «забывает» архитектуру проекта, ваши правки, договорённости, баги и стиль работы.

Вместо того чтобы каждый раз заново объяснять Claude Code, Cursor, Codex или другому агенту, как устроен проект, agentmemory тихо сохраняет полезный контекст, сжимает его в searchable memory и подставляет нужные куски в следующих сессиях.

Что важно:

- работает с Claude Code, Cursor, Codex CLI, Gemini CLI, Windsurf, Roo Code, Cline, Aider и другими агентами
- поддерживает MCP, hooks и REST API
- один общий memory server для разных инструментов
- память шарится между агентами, а не живёт внутри одного клиента
- можно поднимать локально, без завязки на внешний сервис
- помогает не раздувать CLAUDE.md, .cursorrules и другие ручные файлы контекста

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

https://github.com/rohitg00/agentmemory

Ночью сервер сломался, конфиг «никто не трогал», а деплой «точно не виноват»?

Есть простая команда:

find /etc -mtime -1 -type f

Она покажет все файлы в /etc, которые менялись за последние 24 часа.

Нужно проверить сайт - меняешь /etc на /var/www.

Когда все говорят «это не я», find быстро показывает, что реально трогали.

PaddleOCR-VL 1.6 официально вышел

PaddlePaddle выпустили PaddleOCR-VL 1.6 - новую версию модели для распознавания документов.

Результат: 96.33% на OmniDocBench. Это новый SOTA, причём модель обошла как open-source, так и закрытые решения в распознавании текста, формул и таблиц.

Что улучшили:

- первое место на OmniDocBench v1.5 и Real5-OmniDocBench
- заметно лучше распознаёт таблицы, обычный текст и редкие символы
- улучшено распознавание печатей, отдельных фрагментов и графиков
- полная совместимость с архитектурой v1.5
- миграция не нужна - можно подключать как plug-and-play

Где это полезно:

- финансовые контракты
- юридические документы
- исследовательские отчёты
- исторические архивы
- RAG-пайплайны
- подготовка качественных данных для LLM

https://github.com/PaddlePaddle/PaddleOCR

#PaddlePaddle #PaddleOCR #AI #ComputerVision

🚀 Мощный мультимодальный ИИ: Step 3.7 Flash

Step 3.7 Flash — это 198B-параметрическая модель, объединяющая языковую и визуальную обработку для высокопроизводительных задач. Она активирует около 11B параметров на токен, обеспечивая скорость до 400 токенов в секунду и поддерживая контекст до 256k. Идеально подходит для сложных рабочих процессов, таких как анализ финансовых отчетов и взаимодействие с API.

🚀 Основные моменты:
- Высокая производительность в визуальном восприятии и обработке.
- Поддержка многопараметрических задач с высокой точностью.
- Гибкость развертывания в облаке и локально.
- Интеграция с популярными инструментами и платформами.

📌 GitHub: https://github.com/stepfun-ai/Step-3.7-Flash

#python

Python не медленный. Медленным его часто делает ваш код.

У Python есть странная репутация: стоит программе начать тормозить, виноват сразу язык. Но в реальности большая часть быстрых сценариев в Python работает не потому, что интерпретатор внезапно стал магическим, а потому что тяжёлая работа уходит ниже - в C, C++ или Rust.

CPython написан на C. Многие встроенные операции тоже выполняются в C:

- len()
- list.append()
- dict.get()
- sum()
- сортировка
- операции со строками
- часть работы со списками и словарями

Когда вы вызываете list.append(), Python не крутит всю логику добавления элемента на уровне байткода. Он платит небольшой overhead за вызов, а дальше попадает в C-функцию внутри CPython.

Медленный путь начинается там, где мы вручную гоняем данные по одному элементу:

total = 0

for x in data:
    total += x

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

Быстрый путь выглядит иначе:

total = sum(data)

Здесь цикл проталкивается внутрь реализации. Python остаётся удобной оболочкой, а основная работа выполняется ближе к нативному коду.

С NumPy та же идея, только ещё жёстче:

total = np.sum(data)

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

Поэтому фраза «Python медленный» слишком грубая.

Точнее так:

Python-циклы дорогие
C-циклы дешёвые
built-in функции часто быстрее ручного кода
NumPy быстрый не из-за синтаксиса, а потому что не гоняет каждый элемент через интерпретатор
хороший Python-код старается как можно дольше оставаться внутри готовых операций и библиотек

Оптимизация Python часто начинается не с переписывания проекта на Go или Rust, а с простого вопроса:

можно ли убрать ручной цикл и отдать работу тому коду, который уже написан на C, C++ или Rust?

Python хорош не как самый быстрый исполнитель каждой операции.

Он хорош как удобный слой управления над быстрыми нативными кусками.

Когда-то в Python файлы открывали вот так:

f_obj = open(path, 'w')
f_obj.write(some_data)
f_obj.close()

Код короткий, выглядит понятно, но есть проблема: если между open() и close() что-то упадёт, файл может остаться незакрытым.

Поэтому приходилось руками оборачивать всё в try / finally, следить за закрытием ресурса и не забывать cleanup на ошибках.

Потом в Python появился with, и этот бытовой ад стал намного чище:

with open(path, 'w') as f_obj:
f_obj.write(some_data)

Теперь файл закроется автоматически, даже если внутри блока случится исключение.

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

Используется не только для файлов:

- соединения с базой
- lock'и
- временные файлы
- сетевые подключения
- транзакции
- любые объекты с контекстным менеджером

Хороший Python-код часто начинается с простого правила: если ресурс надо открыть и потом закрыть, почти всегда нужен with.

#python