https://github.com/python/cpython/issues/127949
Более никаких asyncio policy.

https://github.com/faster-cpython/ideas/issues/642#issuecomment-2571712347
😁

Тир 1 интерпретатор с tail calls быстрее чем джит :)

В asyncio добавили возможность смотреть граф вызова корутин

Ждем в python3.14: https://github.com/python/cpython/commit/188598851d5cf475fa57b4ec21c0e88ce9316ff0

Пример:

import asyncio

async def test():
    asyncio.print_call_graph()

async def main():
    async with asyncio.TaskGroup() as g:
        g.create_task(test(), name=test.__name__)

asyncio.run(main())

Выведет:

* Task(name='test', id=0x10304eee0)
  + Call stack:
  |   File '/Users/sobolev/Desktop/cpython2/Lib/asyncio/graph.py', line 278, in print_call_graph()
  |   File '/Users/sobolev/Desktop/cpython2/ex.py', line 4, in async test()
  + Awaited by:
    * Task(name='Task-1', id=0x1034a1e60)
      + Call stack:
      |   File '/Users/sobolev/Desktop/cpython2/Lib/asyncio/taskgroups.py', line 121, in async TaskGroup._aexit()
      |   File '/Users/sobolev/Desktop/cpython2/Lib/asyncio/taskgroups.py', line 72, in async TaskGroup.__aexit__()
      |   File '/Users/sobolev/Desktop/cpython2/ex.py', line 7, in async main()

Как оно работает?

Появилось два новых важных изменений:

- Поле Frame.f_generator – оно хранит генератор или корутину, которая владеет данным фреймом. Нужно чтобы отрисовывать + Call stack:
- Новое свойство у Future

    @property
    def _asyncio_awaited_by(self):
        if self.__asyncio_awaited_by is None:
            return None
        return frozenset(self.__asyncio_awaited_by)

Нужно, чтобы отрисовывать + Awaited by:.

Конечно же есть две иплементации. На питоне уже показал, вот так оно на C:

/*[clinic input]
@critical_section
@getter
_asyncio.Future._asyncio_awaited_by
[clinic start generated code]*/

static PyObject *
_asyncio_Future__asyncio_awaited_by_get_impl(FutureObj *self)
/*[clinic end generated code: output=... input=...]*/
{
    /* Implementation of a Python getter. */
    if (self->fut_awaited_by == NULL) {
        Py_RETURN_NONE;
    }
    if (self->fut_awaited_by_is_set) {
        /* Already a set, just wrap it into a frozen set and return. */
        assert(PySet_CheckExact(self->fut_awaited_by));
        return PyFrozenSet_New(self->fut_awaited_by);
    }

    PyObject *set = PyFrozenSet_New(NULL);
    if (set == NULL) {
        return NULL;
    }
    if (PySet_Add(set, self->fut_awaited_by)) {
        Py_DECREF(set);
        return NULL;
    }
    return set;
}

Как использовать?

Конечно же данная фича умеет не только печатать объекты в stdout. Прежде всего – она предоставляет удобное АПИ для различных IDE и дебагеров, которые смогут использовать данную информацию для визуализации: чего вообще у вас там происходит.

Ну и мониторинги, и sentry, и много кто еще получит дополнительную мета-информацию о процессе выполнения кода.

Документация: https://docs.python.org/3.14/library/asyncio-graph.html

Круто?

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

https://peps.python.org/pep-0774/

Коротко говоря: это не отказ от LLVM.

https://discuss.python.org/t/updating-pep-387-to-prefer-5-year-deprecations-instead-of-2-years/65166/35

Теперь для того чтобы удалить что-то, что deprecated - нужно ждать 5 лет.

Как мне кажется, худшее решение за последние годы

История набирает новые обороты
https://discuss.python.org/t/shedding-light-on-a-three-month-suspension/66337/238

Не могу не поздравить одного из самых молодых (вероятно, самого молодого?) контрибьюторов в CPython с победой на олимпиаде PROD - Илью Любавского. Крудописатели, берегитесь!

Привет! Стартуем новый проект для любителей опенсорса: помогаем меинтейнерам и контрибьюторам найти друг друга.

Как оно работает?
- В данном канале меинтейнеры разных Python проектов (от CPython, mypy, Litestar до taskiq) могут в любой момент выложить простые задачки, чтобы люди могли принять участие в разработке их проекта
- Если вы хотите поработать над задачкой – напишите в самой задаче на гитхабе: "Can I work on this?", получите подтверждение меинтейнера и приступайте
- Делитесь успехами / задавайте вопросы в нашем чате @opensource_findings_chat

Если вы меинтейнер какого-то крупного проекта (>= 100 ⭐), то пишите в чат – вас добавят как админа, чтобы вы смогли постить в канал свои задачи. Чем больше – тем лучше, не забывайте ставить тег своей технологии.

Всем хорошего опенсорса!

https://www.youtube.com/watch?v=wgxBHuUOmjA

Добавил ключевое слово maybe в Python3.14

https://github.com/python/cpython/pull/131982 🎉

Решил поучаствовать в конкурсе от GitVerse и соответственно написал статью на хабре:
https://habr.com/ru/articles/899636/
Буду рад вашей критике!

Breaking: PEP 750 - Template Strings был принят:
https://github.com/python/steering-council/issues/275#issuecomment-2794619570

https://playknot.ruff.rs/

Плейграунд для тайпчекера от астралов =)

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

PEP 749 (буквально, пеп о том как будет реализован PEP 649)
принят: https://discuss.python.org/t/pep-749-implementing-pep-649/54974/66

Что ж, annotationlib, добро пожаловать в семью.

Еще одна модель конкурентности в питоне?
https://discuss.python.org/t/add-virtual-threads-to-python/91403

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

Массовые увольнения происходят в Microsoft.
Судя по этому посту, как минимум половина, или возможно даже вся команда Faster-CPython была уволена.
(Faster-CPython team — команда работающая над ускорением CPython, и спонсируемая Microsoft)
Подтверждений этому от самих участников команды еще нет, но это весьма вероятно.

Автор поста на скриншоте непосредственно связан с Faster-CPython team.

К слову, на текущий момент этот пост выглядит иначе (скриншот первоначальной версии поста я честно украл у Никиты Соболева :)).
Автор убрал количество core-developer'ов, и.. непонятно что это значит, честно говоря. Вероятно кого-то все таки не уволили?

Официальное подтверждение тому, что Microsoft более не спонсирует Faster CPython.

Уволили не всех, видимо тех кого не уволили перераспределят на новые проекты.

Люди, которых уволили:
Irit Katriel
Eric Snow
Mark Shannon

Был принят и реализован 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 :)