Был принят и реализован PEP 768.
Он позволяет исполнять код в рамках разных процессов(!) одного хоста.
API довольно простое. sys.remote_exec принимает первым аргументом pid процесса, в котором уже(!) запущен Python-интерпретатор, а второй аргумент путь до файла с Python кодом который нужно исполнить.

Конечно, существуют некоторые ограничения: мажорная и минорная версии интерпретатора, из которого отправляется запрос, должны совпадать с мажорной и минорной версией целевого интерпретатора.
И конечно, целевой интерпретатор должен поддерживать эту фичу, которую можно отключить с помощью -X disable-remote-debug или env-переменной PYTHON_DISABLE_REMOTE_DEBUG.

Безопасно ли это?
Конечно нет. В названии PEP используется слово safe, но оно не про безопасность исполнения кода, а про безопасное API что б "присоединяться" к Python-процессам, что может быть полезно для дебаггеров, например для pdb -p.


Теперь о самом интересном. Как же это реализовано?
- Windows: https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-writeprocessmemory
- UNIX: https://linuxman7.org/linux/man-pages/man2/process_vm_readv.2.html
- macOS: https://developer.apple.com/documentation/kernel/1402070-mach_vm_write

Все это позволяет нам писать в нужную область памяти целевого процесса.
Отлично, мы записали информацию (конкретно, путь до файла с Python кодом который нужно исполнить). Что дальше?
Теперь дело остается за целевым процессом.
Здесь у нас есть два варианта.
1) Как вы можете знать, в Python существуют обработчики сигналов. Именно в общем обработчике сигналов как раз и проверяется, нет ли у нас <входящих запросов> на выполнение кода. Если таковые есть — считываем Python код из пути что нам отправили и выполняем его.
Почему обработка подобных запросов находится в обработчике сигналов, хотя ничего из этого не относится к сигналам?
Думаю, дело в частых попытках обработать сигналы, соответственно там же мы можем и проверить входящие запросы на исполнение Python кода. Согласно PEP, код который мы отправили будет исполнен в "следующий возможный момент", что как раз и попадает под обработку сигналов.

2) В самом интерпретаторе есть обработка "внутренних запросов":
— "stop-the-world" (пауза для сборки мусора)
— обработка тех самых сигналов :)
— обработка асинхронных исключений
— запуск сборки мусора
Теперь к этому списку добавилась обработка запросов на исполнение кода.


Осталось только что б кто-то на основе этого построил RPC :)

https://www.microsoft.com/en-us/research/wp-content/uploads/2025/04/pyrona_camera_ready.pdf

Paper от Faster-CPython team: "Dynamic Region Ownership for Concurrency Safety"

PEP 734: Multiple Interpreters in the Stdlib (Публичное Python API к сабинтерпретаторам) был принят:
https://discuss.python.org/t/pep-734-multiple-interpreters-in-the-stdlib/41147/36

Вообще, уже был достигнут feature-freeze для 3.14 (после этого момента не добавляются никакие новые фичи), но руководящий совет решил сделать исключение.
🥳

Реализация PEP 734 возможно будет отложена до 3.15.
Автор PEP Эрик Сноу, не согласен с решением руководящего совета о переименовании модуля из interpreters в concurrent.interpreters: https://discuss.python.org/t/decision-making-process-improvements-or-my-frustrations-with-how-pep-734-has-played-out/95985

За ссылку спасибо @mikhail_efimov

https://discuss.python.org/t/introducing-cpython-memory-tracker/96721

Потыкать на мок данных можно тут: https://memory.python.org/

Никита - один из самых известных русскоязычных опенсорс разработчиков (в том числе участник CPython core team 😎).
Советую подписаться на его канал - @opensource_findings где он часто освещает новинки в Питоне и не только!
Так же советую посмотреть его курс лекций по внутренностям CPython - тык!

Никита занимается опенсорсом фуллтайм, и будет рад если вы его поддержите - https://boosty.to/sobolevn

Менеджера команды Faster-CPython переманила к себе Nvidia. Стоит учесть, что из Microsoft при недавних увольнениях он не был затронут.

Вероятно, остальных ребят из Faster-CPython тоже переманили :)

Статья на тему перевода CPython со стэковой виртуальной машины на регистровую.
https://dl.acm.org/doi/pdf/10.1145/3568973

Большая бесплатная Python конференция в Нижнем Новгороде!

У меня хорошая новость. Делаем бесплатную конфу по питону, пригласили топовых специалистов: core-разработчиков, контрибьюторов, организаторов разных комьюнити движух, специалистов из индустрии. И все – участники нашего чата. Как же так получилось 🌚

Вот такой список докладов:

- Подопригора Кирилл, CPython core dev, Evrone: Кто такой CFG в CPython, и какую роль он выполняет?
- Хитров Николай, организатор @peer_2beer, Точка Банк: Проектирование — это когда чувствуешь, а не какие-то там циферки
- Ильиных Илья, организатор @spbpythonnews, блоггер @kydavoiti: Vim — это метаредактирование
- Джалаев Давид, Газпром-нефть ЦР: Continuous profiling
- Порядин Алексей, участник @pytho_nn: AI-агенты в каждый дом
- Мирянов Сергей, CPython contributor, РН-Технологии: Внутреннее устройство сборки мусора в CPython 3.14+
- Неретин Степан, CPython contributor, Postgres Professional: Своя файловая система за 5 минут на Python
- Ефимов Михаил, CPython contributor, X5 Tech: Генератор байткода и байткод генератора

Ну мощь же 💪
Да, конференции можно делать и не за 50 тыщ за билет.

А еще будет много доброго общения, обсуждения кишочков питона, настолки и тусовка до утра :)
Идеальный день.

Бронируйте дату! Если давно хотели побывать в Нижнем – вот идеальный повод. Буду рад всех видеть лично!

📍 Когда: 20 сентября 2025 года
📍 Где: ул. Нижне-Волжская набережная, 11, «Академия Маяк» им. А.Д. Сахарова

Регистрация обязательна: https://dev.itgorky.ru

| Поддержать | YouTube | GitHub | Чат |