Zen of Python
18.9K subscribers
1.39K photos
202 videos
38 files
3.56K links
Полный Дзен Пайтона в одном канале

Разместить рекламу: @tproger_sales_bot

Правила общения: https://tprg.ru/rules

Другие каналы: @tproger_channels

Сайт: https://tprg.ru/site

Регистрация в перечне РКН: https://tprg.ru/xZOL
Download Telegram
Как выбрать между threading, asyncio и процессами, не переписывая код четыре раза

Модель конкурентности обычно берут ту, что уже стоит в соседнем модуле, а не ту, что подходит нагрузке. Пока задача упирается в сеть, ошибиться сложно: ждёт всё равно не процессор. На счётной задаче цена решения видна сразу.

В руководстве Real Python одна и та же задача написана в четырёх версиях: синхронной, на потоках, на asyncio и на процессах. И так дважды: сначала для нагрузки, где программа ждёт ответа по сети, потом для той, где она считает. Восемь реализаций одной задачи.

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

#python
4
Питонисту советуют TypeScript ради типов, которые у него уже есть

У питониста в CI давно стоит mypy, а аргументы за TypeScript ему перечисляют те же: типы ловят ошибки до запуска, интерфейсы фиксируют форму объекта, вывод типов экономит аннотации. Из этого набора собран и гайд для питонистов на dev.to.

Разница начинается дальше, в судьбе самих типов. В TypeScript они стираются при компиляции, и входящий JSON всё равно приходится проверять руками или через zod. В Python аннотации остаются в объекте: их читает pydantic, на них держится валидация в FastAPI, один и тот же тип работает и в проверке схемы, и в разборе запроса.

Одни считают, что после mypy в TypeScript идти незачем: тот же контракт, только с npm. Другие говорят, что tsc дисциплинирует сильнее mypy, который на чужом коде молча сдаётся на Any.

А по вашему опыту?

#python
ffmpeg вернул нулевой код возврата, а видео на выходе оказалось битым

Внешние утилиты из Python проверяют обычно одинаково: subprocess.run(..., check=True), и раз исключения нет, значит всё получилось. С ffmpeg этого мало: он спокойно отрабатывает с нулевым кодом и отдаёт файл, собранный не из тех фрагментов, которые вы просили, а заметить это можно, только досмотрев результат до конца.

В ReelCraft, CLI на Python для сборки ролика из папки с фото и видео, такое случилось трижды: Gemini 3.7 Flash разбирает ассеты и предлагает список нарезки, ffmpeg режет по нему, оба этапа отчитываются об успехе. Что именно разъехалось в склейке и субтитрах, разбирает дев-лог автора.

Приём оттуда полезен и без видео: между выводом модели и вызовом ffmpeg лежит edl.yaml, который человек читает и подтверждает руками. И проверять после subprocess стоит артефакт, тем же ffprobe, а не код возврата.

#python
deepcopy копирует всё, до чего дотянется, включая то, что вы копировать не собирались

Знакомая поломка: конфиг сложили в словарь, сделали copy.copy, поправили вложенный список в клоне и увидели правку в оригинале. Новый контейнер получает те же ссылки на вложенные объекты.

copy.deepcopy идёт по графу рекурсивно и ведёт словарь memo: каждый скопированный объект запоминается по id. Циклическая ссылка поэтому не уводит копирование в бесконечность, а два поля, смотревшие на один список, в копии тоже смотрят на один. Плата — обход всего графа: объект, который держит открытый сокет или пул соединений, deepcopy либо уронит, либо утащит за собой пол-приложения.

Поведение настраивается методами __copy__ и __deepcopy__: класс сам решает, что воспроизвести заново, а что отдать по ссылке.

Разбор поверхностной и глубокой копии — в статье на dev.to.

#python
1