ru
Feedback
CPython notes

CPython notes

Открыть в Telegram
1 441
Подписчики
Нет данных24 часа
+17 дней
+830 день
Архив постов
Решил поучаствовать в конкурсе от GitVerse и соответственно написал статью на хабре: https://habr.com/ru/articles/899636/ Буду рад вашей критике!

https://www.youtube.com/watch?v=wgxBHuUOmjA Добавил ключевое слово maybe в Python3.14 https://github.com/python/cpython/pull/131982 🎉

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

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

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

https://discuss.python.org/t/updating-pep-387-to-prefer-5-year-deprecations-instead-of-2-years/65166/35 Теперь для того чтобы удалить что-то, что deprecated - нужно ждать 5 лет. Как мне кажется, худшее решение за последние годы

https://peps.python.org/pep-0774/ Коротко говоря: это не отказ от LLVM.

В 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://github.com/faster-cpython/ideas/issues/642#issuecomment-2571712347 😁 Тир 1 интерпретатор с tail calls быстрее чем джит :)

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

PhD thesis о конструировании высокопроизводительных виртуальных машин для динамических языков. Я с некоторой долей вероятности уверен что текущие оптимизации в CPython в какой-то мере основаны на этой работе. Ее автор кстати участник faster-cpython команды :) https://theses.gla.ac.uk/2975/1/2011shannonphd.pdf За ссылку спасибо @mikhail_efimov!

https://discuss.python.org/t/an-analysis-of-return-in-finally-in-the-wild/70633 Дискуссия о использования return в finally блоке. Вероятно, PEP 601 который предлагает запретить return/break/continue в finally блоке будет вновь рассмотрен.

Был смержен тред-локал байткод - https://github.com/python/cpython/pull/123926 Зачем это нужно и как это связано с nogil aka free-threaded? Напомню, что в версии 3.11 был добавлен так называемый <адаптивный> интерпретатор, который умеет в специализацию. Типичная операция x + y в обычном случае превращается в BINARY_OP опкод, который делает x.__add__(y), что несомненно не очень-то и дешево, так как надо производить лукап __add__ и прочие связанные с этим операции. Адаптивный интерпретатор "подстраивается" под ситуации когда у вас достаточно много случаев в коде когда в операции x + y оба операнда являются интами, и тогда можно сэкономить на лукапе и дергать специализированную сишную функцию для сложения интов, которая не производит никакого лукапа атрибутов, и именно на этом мы выигрываем по производительности. Так вот, в случае с nogil сборкой адаптивный интерпретатор не является потокобезопасным, что делало nogil сборку действительно медленнее(потому что специализация была выключена в nogil сборке). Pull request отмеченный выше делает адаптивный интерпретатор потокобезопасным и вместе с этим у codeobject появляется атрибут co_tlbc :)

Питон самый популярный язык на гитхабе
Питон самый популярный язык на гитхабе

photo content
+1