PyObject *
_Py_MakeCoro(PyFunctionObject *func)
{
    int coro_flags = ((PyCodeObject *)func->func_code)->co_flags &
        (CO_GENERATOR | CO_COROUTINE | CO_ASYNC_GENERATOR);
    assert(coro_flags);
    if (coro_flags == CO_GENERATOR) {
        return make_gen(&PyGen_Type, func);
    }
    if (coro_flags == CO_ASYNC_GENERATOR) {
        return make_gen(&PyAsyncGen_Type, func);
    }

    assert (coro_flags == CO_COROUTINE);
    PyObject *coro = make_gen(&PyCoro_Type, func);
    return coro;
}

Вот тут как раз при выполнении функции и будут создаваться инстансы types.GeneratorType и types.CoroutineType.

Вот и вся разница :)

Дальше уже во многих местах на основе флагов / методов - объекты начинают вести себя по-разному. Однако, все еще генератор можно превратить в корутину при помощи types.coroutine

Узнали сегодня что-то новое?

Кстати, у нас в Нижнем Новгороде будет митап по питону 22 ноября: https://t.iss.one/pytho_nn/15099

4 крутейших спикера:
- "Уязвимый" Python – Юлия Волкова (CodeScoring, Санкт-Петербург)
- "Английский для разработчика" – James Stuart Black (JB Teach, Нижний Новгород)
- "Программирование и искусство" – Дмитрий Сошников (НИУ ВШЭ/МАИ/Yandex Cloud, Москва)
- "Квантовое программирование на Python: Погружение в квантовые вычисления для разработчиков" – Бейлак Алиев (Райффайзен банк, Москва)

И еще:
- Общение в баре после митапа
- Игра в мою настолку: https://github.com/sobolevn/ship-it-boardgame

Регистрация: https://pytho-nn.timepad.ru/event/3089004/
Чат местного сообщества: @pytho_nn

Если будете в Нижнем - заходите! Ждем всех любителей питонов :)

Как работает диспатчеризация байткода внутри VM? Computed GOTOs

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

#define LOAD_CONST 79

PyObject* _Py_HOT_FUNCTION
_PyEval_EvalFrameDefault(PyThreadState *tstate, 
                         _PyInterpreterFrame *frame, 
                         int throwflag)
{
    DISPATCH_GOTO();  // разворачивается в `goto dispatch_opcode`
dispatch_opcode:
    switch (opcode) {
        TARGET(LOAD_CONST):  // разворачивается в `case 79:`
        {   
            frame->instr_ptr = next_instr;
            next_instr += 1;
            _PyStackRef value = PyStackRef_FromPyObjectNew(
                GETITEM(FRAME_CO_CONSTS, oparg));
            // ...
        }
        // ...
    }

    opcode = next_instr->op.code;
    DISPATCH_GOTO();  // разворачивается в `goto dispatch_opcode;`

exit:
    // end of cycle: success or error
}

Но, на самом деле – все не совсем так просто! Данный switch по сути является самой горячей частью кода во всем интерпретаторе, он выполняется буквально на любое действие. Любое ускорение данного места дает ускорение всему коду на питоне. А значит – такие ускорения были придуманы.

Концепт Computed GOTOs

Вводная статья на тему, кто вообще никогда о таком не слышал. Если очень кратко:
- Создаем известную в compile-time таблицу переходов, которая использует лейблы для goto. Назовем ее opcode_targets
- Вместо switch просто используем goto *opcode_targets[opcode]
- Проверяем в configure, что компилятор поддерживает такую фичу (`gcc` поддерживает, --with-computed-gotos по-умолчанию включено)
- Накручиваем DSL для виртуальной машины:

#if USE_COMPUTED_GOTOS
#  define TARGET(op) TARGET_##op:
#  define DISPATCH_GOTO() goto *opcode_targets[opcode]
#else
#  define TARGET(op) case op: TARGET_##op:
#  define DISPATCH_GOTO() goto dispatch_opcode
#endif

Итого, используя тот же DSL на макросах, благодаря флагу USE_COMPUTED_GOTOS (который выставляется в configure) – получаем совсем другой код в _PyEval_EvalFrameDefault:

#define LOAD_CONST 79

PyObject* _Py_HOT_FUNCTION
_PyEval_EvalFrameDefault(PyThreadState *tstate, 
                         _PyInterpreterFrame *frame, 
                         int throwflag)
{
    DISPATCH_GOTO(); // // goto *opcode_targets[opcode]
    TARGET(LOAD_CONST): // TARGET_79:
    {  
        frame->instr_ptr = next_instr;
        next_instr += 1;
        _PyStackRef value = PyStackRef_FromPyObjectNew(
            GETITEM(FRAME_CO_CONSTS, oparg));
        // ...
    }
    // ...

    opcode = next_instr->op.code;
    DISPATCH_GOTO();  // goto *opcode_targets[opcode]

exit:
    // end of cycle: success or error
}

Данная реализация где-то на 15% быстрее реализации на switch. Но для простоты все продолжают говорить, что внутри VM switch+case

Узнали сегодня что-то новое? :)

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

Лучший курс по Python 11: bytearray

42 минуты С-шного хардкора про bytearray, что может быть лучше?

https://www.youtube.com/watch?v=5UFx29EVlkU

В видео будет про:
- Разные аллокаторы в CPython: PyMem_Malloc и PyMem_Realloc
- C-pointer math (для самых маленьких)
- Разные хитрые оптимизации для работы с bytearray

Бонус 1

Я обещал поделиться логикой стратегии изменения размера bytearray.

Бонус 2

Интересный вопрос, который я не осветил в видео. Почему код работает так?

>>> b = bytearray(b'1234')
>>> del b[:4:2]
>>> b.__alloc__()
5

Почему так?

1. Вызывается функция: bytearray_ass_subscript
2. values будет NULL, потому как удаление (сишный аналог __delitem__ из питона работает так)
3. Дальше распаковываем slice в переменные тут
4. Удаляем тут хитрым и достаточно быстрым способом

Ответы

Ответ на вопрос из видео с поиском бага на слайде в Cшном коде: https://github.com/python/cpython/pull/126981

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

Аллокаторы в СPython: PyArena

Один из самых простых аллокаторов в питоне. Исходники.

По сути данный аллокатор является небольшой оберткой поверх PyMem_Malloc, но с интересной особенностью. Если PyMem_Malloc имеет PyMem_Free для освобождения памяти каждого конкретного объекта, то PyArena имеет только _PyArena_Free(PyArena *arena) для освобождения сразу всей арены со всеми объектами, которые являются ее частью.

Смотрим:

struct _arena {
    /* Pointer to the first block allocated for the arena, never NULL.
       It is used only to find the first block when the arena is
       being freed. */
    block *a_head;

    /* Pointer to the block currently used for allocation.  Its
       ab_next field should be NULL.  If it is not-null after a
       call to block_alloc(), it means a new block has been allocated
       and a_cur should be reset to point it. */
    block *a_cur;

    /* A Python list object containing references to all the PyObject
       pointers associated with this arena.  They will be DECREFed
       when the arena is freed. */
    PyObject *a_objects;
};

Как мы видим, арена содержит два указателя на блоки. А вот и они:

typedef struct _block {
    /* Total number of bytes owned by this block available to pass out.
        Read-only after initialization.  The first such byte starts at
        ab_mem */
    size_t ab_size;

    /* Total number of bytes already passed out.  The next byte available
        to pass out starts at ab_mem + ab_offset */
    size_t ab_offset;

    /* An arena maintains a singly-linked, NULL-terminated list of
        all blocks owned by the arena.  These are linked via the
        ab_next member */
    struct _block *ab_next;

    /* Pointer to the first allocatable byte owned by this block.  Read-
        only after initialization */
    void *ab_mem;
} block;

И очищаем сразу все внутри арены:

void _PyArena_Free(PyArena *arena)
{
    assert(arena);
    // ...
    block_free(arena->a_head);
    Py_DECREF(arena->a_objects);
    PyMem_Free(arena);
}

Обратите внимание, что у PyArena есть block'и и есть список обычных PyObject *. Что достигается за счет следующих АПИ:
- _PyArena_New – создает новую арену и выделяет память под нее. Создает пустой список под будущие объекты
- _PyArena_Free – очищает память существующей арены. Удаляет все блоки из памяти, декрефит объекты в списке, их собирает reference-counter
- _PyArena_Malloc – создает новый block нужного размера и сохраняет указатель на него в single-linked list
- _PyArena_AddObject – добавляет PyObject * в список отслеживаемых объектов и гарантирует, что он будет жить столько, сколько живет сама арена

Использование

Где нужна арена? На самом деле – много где. Сам подход с ареной – можно сравнить с lifetime из Rust. Все объекты внутри арены живут до одного общего конца.

Используется там, где объекты логически имеют общий lifetime. Например, при парсинге кода в AST. Ведь все дерево объектов в AST – имеет общий лайфтайм. Так намного проще обрабатывать ошибки, если произошло что-то плохое, мы просто убиваем всю арену. И нам не надо чистить все объекты в памяти ручками.

Крайне удобная штука.

Большая статья по теме: https://rfleury.com/p/untangling-lifetimes-the-arena-allocator

Выводы

Вот и single-linked list с алгособесов пригодился! 🌚️️️️

Кто парсит парсер? Метаграмматики

Звучит как название нового фильма Марвел, но на самом деле – перед нами достаточно интересная задача.

В CPython с недавних пор (вспоминаем проект Guido van Rossum по внедрению PEG парсера) грамматика описана вот так (ссылка):

lambdef[expr_ty]:
    | 'lambda' a=[lambda_params] ':' b=expression {
        _PyAST_Lambda((a) ? a : CHECK(arguments_ty, _PyPegen_empty_arguments(p)), b, EXTRA) }

lambda_params[arguments_ty]:
    | invalid_lambda_parameters
    | lambda_parameters

На данном примере – грамматика для описания lambda функций.

Что здесь что?
- lambdef и lambda_params обозначают названия правил
- [expr_ty] и [arguments_ty] – метаинформация, которая будет использована парсером позже. Тут буквально куски C кода написаны
- У правил есть варианты: описаны через |, сначала пробуем первое, потом второе и тд
- Правила "складываются" в более сложные правила. Напимер lambdadef содержит в себе: a=[lambda_params] (что конечно же обозначает парсинг параметров lambda функции)
- 'lambda' – обозначает ключевое слово lambda, а ':' - физический символ : в коде
- Внутри {} у нас снова идет C код: данная часть называется "действием", она буквально описывает, какой C код вызывать при успешном парсинге данного правила. _PyAST_Lambda((a) ? a : CHECK(arguments_ty, _PyPegen_empty_arguments(p)), b, EXTRA) – в нашем случае вызывает функцию _PyAST_Lambda

И так мы маленькими кусочками описываем всю большую грамматику Python. Разобрались.

Команда make regen-pegen позволит вам автоматически сгенерировать C парсер из грамматики выше. И получится вот такое:

if (
    (_keyword = _PyPegen_expect_token(p, 609))  // token='lambda'
    && (a = lambda_params_rule(p), !p->error_indicator)  // lambda_params?
    && (_literal = _PyPegen_expect_token(p, 11))  // token=':'
    && (b = expression_rule(p))  // expression
)
{
    Token *_token = _PyPegen_get_last_nonnwhitespace_token(p);

    _res = _PyAST_Lambda(
        (a) ? a : CHECK(arguments_ty, _PyPegen_empty_arguments(p)), 
        b, EXTRA);
    goto done;
}

И уже данный парсер будет вызван, чтобы превратить lambda x, y: ... в AST при работе питона. Подводка закончена.

Что за метаграмматики?

Ключевой вопрос: а кто парсит файл с грамматикой? Кто определяет, что такое "правило", "варианты", "действие"?

Оказывается, что в питоне есть еще один уровень грамматик. Грамматика, которая определяет правила основной грамматики. Мы её так и называем – метаграмматика.

Выглядит она вот так:

rule[Rule]:
    | rulename memoflag? ":" alts NEWLINE INDENT more_alts DEDENT {
          Rule(rulename[0], rulename[1], Rhs(alts.alts + more_alts.alts), memo=opt) }
    | rulename memoflag? ":" NEWLINE INDENT more_alts DEDENT {
          Rule(rulename[0], rulename[1], more_alts, memo=opt) }
    | rulename memoflag? ":" alts NEWLINE { Rule(rulename[0], rulename[1], alts, memo=opt) }

Здесь мы как раз видим в похожем синтаксисе определение, что такое "правило": с "именем" правила и "альтернативами".

Здесь тоже есть куски кода: [Rule] и Rule(rulename[0], rulename[1], Rhs(alts.alts + more_alts.alts), memo=opt), но они уже на питоне. Потому что метаграмматика генерирует парсер для грамматики на питоне:

@memoize
def rule(self) -> Optional[Rule]:
    # rule: rulename memoflag? ":" alts NEWLINE INDENT more_alts DEDENT | rulename memoflag? ":" NEWLINE INDENT more_alts DEDENT | rulename memoflag? ":" alts NEWLINE
    mark = self._mark()
    if (
        (rulename := self.rulename())
        and (opt := self.memoflag(),)
        and (literal := self.expect(":"))
        and (alts := self.alts())
        and (_newline := self.expect('NEWLINE'))
        and (_indent := self.expect('INDENT'))
        and (more_alts := self.more_alts())
        and (_dedent := self.expect('DEDENT'))
    ):
        return Rule(rulename[0], rulename[1], 
                    Rhs(alts.alts + more_alts.alts), memo=opt)

Запускаем make regen-pegen-metaparser, и получаем на выходе питоновский парсер для грамматик.

Финалим

- Метаграмматика создает метапарсер на питоне для парсинга грамматики
- Метапарсер парсит грамматику и создает парсер на Си
- Си парсер парсит наш код на питоне

Но где грамматика для метаграмматики? Ответ можно найти тут.

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

Как работает CI для опенсорса?

Любой крупный опенсорс проект невозможен без обильного тестирования. CI-сервисы уже многие годы являются нашими обязательными спутниками. Но как они работают?

Давайте разбирать на примере GitVerse.

Важнейшие части:
- репозиторий – откуда мы берем задачи и код для запуска;
- DSL – описание того, как и что мы будем запускать. Обычно в yaml;
- runner (self-hosted или shared) – где мы запускаем определенные нами задачи.

Поговорим про две последние части.

DSL

С DSL все очень интересно. В GitVerse синтаксис и рантайм совместимы с GitHub Actions — значит, можно переиспользовать почти все существующие actions из маркетплейса.

Пример переиспользования wemake-python-styleguide GHA можно найти тут:

name: wps
'on':
  push:
    branches:
      - master
  pull_request:
jobs:
  build:
     runs-on: ubuntu-cloud-runner  # <- отличие от GHA
     steps:
     - uses: actions/checkout@v4
     - uses: wemake-services/wemake-python-styleguide@master

Работает! Вот ссылка на логи.

Пока есть проблемы с actions/cache, но обещают скоро пофиксить.

Runner

Как и всегда: можно делать свои self-hosted раннеры, есть простой способ завести раннеры в cloud.ru, есть hosted runners от платформы.

Что интересно? Интересно, что сам раннер построен поверх таскраннера act, который умеет запускать GitHub Actions локально. Документация тут. Можно попробовать запустить мой пример локально:

» act -W .gitverse/workflows/wps.yaml --container-architecture linux/amd64 -P ubuntu-cloud-runner=node:16-buster-slim

[wps]   ☁  git clone 'https://github.com/wemake-services/wemake-python-styleguide' # ref=master
[wps] ⭐ Run Main actions/checkout@v4
[wps]   🐳  docker cp src=/Users/sobolev/Desktop/wps-test/. dst=/Users/sobolev/Desktop/wps-test
[wps]   ✅  Success - Main actions/checkout@v4
[wps] ⭐ Run Main wemake-services/wemake-python-styleguide@master
[wps]   ❌  Failure - Main wemake-services/wemake-python-styleguide@master
[wps]   ⚙  ::set-output:: output=./script.py
  2:1   WPS421 Found wrong function call: print
  print('hello world')
  ^
[wps] 🏁  Job failed

Круто?

Внутри self-hosted runner выполняется похожий код. В GitVerse есть свой act_runner поверх act, чтобы было удобнее. Там гошный standalone бинарник, легко скачать и использовать.

Пока hosted runners в бете, но их постепенно выкатывают на всех пользователей. Если у вас что-то не работает, то создать багу можно тут.

Послесловие

Ребята из GitVerse решили поддержать мою работу в опенсорсе, что огромная редкость в наших реалиях.
Большое им спасибо.

Реклама. АО «СберТех» ИНН: 7736632467. erid: 2W5zFHCJ2RN

[email protected] релизнут!

https://github.com/wemake-services/wemake-python-styleguide/releases/tag/1.0.0

Самый строгий линтер в мире стал еще строже и еще удобнее.

ruff

Некоторое время назад я понял, что если сейчас не поддержать ruff, то проект умрет. Сказано – сделано.
Теперь wemake-python-styleguide поддерживает работу вместе с ruff. Что оно означает на практике?

- Теперь WPS не выкидывает никаких ошибок, которые противоречили бы ruff. Например, я убрал все стилистические правила, чтобы решать все простым ruff format
- Все дублирующие правила из WPS были убраны в пользу ruff. Ведь ruff быстрее их находит и некоторые даже фиксит
- Теперь можно использовать ruff check && ruff format && flake8 --select=WPS ., WPS, конечно, может найти дополнительные ошибки, но не будет конфликтовать с ruff как раньше
- Поддержка полная. От preview = true до самых заковыристых правил PyLint, да теперь WPS совместим с PyLint из ruff

Black, кстати, теперь тоже поддерживается.

Конфигурацию можно найти тут.

Что еще интересного в релизе?

- Множество новых правил сложности
- Крутая поддержка match и case. Находим дубликаты case условий, проверяем сложность, находим много разных ошибок
- Много новой конфигурации, чтобы точечно настраивать отдельные правила линтера
- Куча багов поправлено!

Статистика релиза:
- WPS стал минимум в 2.4 х быстрее, потому что я удалил много кода и много flake8 плагинов
- Количество коммитов с прошлого релиза: 294
- Количество задач, которые я закрыл в процессе работы (с 195 до 26) = ~170
- Изменений: 490 файлов, +15к, -26к
- Количество контрибьюторов в проект достигло двухсот!

Страдайте Наслаждайтесь! Всех с наступающим 🎄

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

Статический анализ GitHub Actions

Сразу после релиза новой версии линтера, я задался вопросом обновления своего шаблона для создания новых питоновских библиотек: https://github.com/wemake-services/wemake-python-package

И я понял, что я несколько отстал в вопросе стат анализа GitHub Actions и прочей инфраструктуры.
Расскажу о своих находках.

pre-commit ci

Все знают про пакет pre-commit? Несколько лет назад он получил еще и свой собственный CI, который умеет запускаться без дополнительного конфига. И автоматически пушить вам в ветку любые изменения. Что супер удобно для всяких ruff / black / isort и прочего. У нас такое стоит в большом количестве проектов. Вот пример из typeshed. Вот что поменялось автоматически.

Строить CI на базе pre-commit очень удобно, потому что тебе просто нужно скопировать пару строк в конфиг. А плюсов много:
- Автоматически исправляются многие проблемы
- Автоматически запускается CI, 0 настроек
- Локально все тоже работает одной командой: pre-commit run TASK_ID -a

actionlint

Первый раз я увидел actionlint внутри CPython и затащил его в mypy. Actionlint на #go, он предлагает набор проверок для ваших GitHub Actions от безопасности до валидации спеки вашего yml. Довольно полезно, позволяет найти много мест для улучшений.

test.yaml:3:5: unexpected key "branch" for "push" section. expected one of "branches", ..., "workflows" [syntax-check]
  |
3 |     branch: main
  |     ^~~~~~~
test.yaml:10:28: label "linux-latest" is unknown. available labels are "macos-latest", ..., "windows". if it is a custom label for self-hosted runner, set list of labels in actionlint.yaml config file [runner-label]
   |
10 |         os: [macos-latest, linux-latest]
   |                            ^~~~~~~~~~~~~
test.yaml:13:41: "github.event.head_commit.iss.onessage" is potentially untrusted. avoid using it directly in inline scripts. instead, pass it through an environment variable. see https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions for more details [expression]
   |
13 |       - run: echo "Checking commit '${{ github.event.head_commit.iss.onessage }}'"
   |                                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Даже умеет автоматом shellcheck запускать на ваши run: скрипты!

zizmor

Исходники. Уже на #rust, он более злой. Делает похожие вещи: находит проблемы безопасности. Находит много проблем.

Вот пример, сколько всего он нашел в mypy.

warning[artipacked]: credential persistence through GitHub Actions artifacts
  --> mypy/.github/workflows/mypy_primer.yml:37:9
   |
37 |         - uses: actions/checkout@v4
   |  _________-
38 | |         with:
39 | |           path: mypy_to_test
40 | |           fetch-depth: 0
   | |________________________- does not set persist-credentials: false
   |
   = note: audit confidence → Low

error[dangerous-triggers]: use of fundamentally insecure workflow trigger
 --> mypy/.github/workflows/mypy_primer_comment.yml:3:1
  |
3 | / on:
4 | |   workflow_run:
... |
7 | |     types:
8 | |       - completed
  | |_________________^ workflow_run is almost always used insecurely
  |
  = note: audit confidence → Medium

check-jsonschema

Еще есть вот такой проект, он в основном полезен за счет доп интеграций: можно проверять dependabot.yml, renovate.yml, readthedocs.yml и многое другое.

Ставится просто как:

  - repo: https://github.com/python-jsonschema/check-jsonschema
    rev: 0.30.0
    hooks:
      - id: check-dependabot
      - id: check-github-workflows

Выводы

Как всегда – статический анализ многому меня научил. Я узнал много нового про безопасность GitHub Actions, про вектора атаки, про лучшие практики. А сколько проблем в ваших actions?

Скоро ждите весь новый тулинг в python шаблоне v2025 😎

LaranaJS – Рендерим фронтенд в картинку! 🌚

LaranaJS – это большой эксперимент по поиску альтернативных способов рисовать графические интерфейсы. Если большинство других фреймворков полагаются на такие устаревшие технологии как HTML и CSS и вендорлочат себя на браузеры, то Larana делает всё иначе.

Вот как устроены сетевые взаимодействия в LaranaJS.

Браузер запрашивает страницу

На этом этапе происходят создание сессии, резолв роута и инициализация страницы. В то же время разные подсистемы (рендерер, менеджер сессий, роутер и т. д.) генерируют клиентский код — он минимальный – просто canvas и немного работы с сетью по вебсокетам:

<html>
 <!--Minimal head-->
 <body>
  <canvas id="canvas"></canvas>
  <script>
   // Network code
  </script>
 </body>
</html>

Клиент открывает соединение

При полной загрузке страницы создаётся подключение по веб-сокетам и начинается обмен сообщениями:

- Сервер отрисовывает UI в виде изображения (png) и отправляет его на клиент.
- Клиент принимает изображение и вставляет его в canvas.

Все дальнейшие взаимодействия происходят в виде обмена событиями – действия пользователя отправляются клиентом, команды и изображения отправляются сервером.

// event
{
 "event": "mousemove",
 "x": 0,
 "y": 0,
}
// response
{
 "image": "", // изображение в base64
 "x": 0, // координаты для вставки изображения
 "y": 0,
 "w": 0,
 "h": 0,
}

Такая архитектура позволяет сократить размер клиента до 6KB #js и запускаться в любом браузере c 2009 года. При этом есть возможность написать собственное клиентское приложение и запускать его хоть на esp32 с подключённым дисплеем.

Несмотря на новизну подхода, сама разработка интерфейсов остаётся привычной. Например, вот код страницы с типичным каунтером:

class HomePage extends Page {
 title() {
  return 'Hello, World!'
 }

 init() {
  const { initState } = this.useState()
  initState({ counter: 0 })
 }

 root() {
  return layout({
   style: 'row',
   children: [
    button({ text: '+', onClick: () => this.increment() }),
    text({ model: 'counter' }),
    button({ text: '-', onClick: () => this.decrement() }),
   ],
  })
 }
}

Большинство задач можно решить с помощью готовых компонентов. Но если есть необходимость сделать что-то необычное, то есть прямой доступ к созданию команд для рендеринга в компоненте figure. Например, рисовать сложные фигуры вроде снежинок:

root() {
 return figure({
  template: (fig, queue) => {
   line({
    borderColor: '#aaaaff',
    borderWidth: 2,
    points: [
     point({ x: x - halfRadius, y: y - halfRadius }),
     point({ x: x + halfRadius, y: y + halfRadius }),
     point({ x: x + halfRadius, y: y - halfRadius, moveTo: true }),
     point({ x: x - halfRadius, y: y + halfRadius }),
     point({ x: x + halfRadius, y, moveTo: true }),
     point({ x: x - halfRadius, y }),
     point({ x, y: y - halfRadius, moveTo: true }),
     point({ x, y: y + halfRadius }),
    ],
   }).to(queue)
  },
 })
}

Специально для этого поста я подготовил новогоднее демо:

- Репозиторий: https://github.com/laranatech/snowflakes-demo
- Потыкать: https://snowflakes.larana.tech

Подсистемы

Выше я упоминал подсистемы вроде рендерера и менеджера сессий. Они уже вшиты в фреймворк и можно использовать готовые. Можно написать и собстенные, а потом просто добавить их в приложение:

const app = new LaranaApp({
 config,
 renderer: new ClientRenderer({}),
 sessionManager: new MemorySessionManager({}),
 router: new DefaultRouter({ routes }),
})

app.run()

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

Больше подобного авангарда в канале @laranatech!
Автор: @e_kucheriavyi

Лучший курс по Python 12: tuple

https://youtube.com/watch?v=P5OY3Y4Fc7k

Я решил окончательно упороться: сделал видео про tuple на 1ч 30м. Зато я рассказал про tuple вообще все, что знал сам. Для джунов:

- В чем разница между tuple и list?
- Аннотации tuple
- Тип произведение
- TypeVarTuple, PEP646, Unpack

Для мидлов:
- ast.Tuple
- tuple_iterator
- collections.abc
- collections.namedtuple
- typing.NamedTuple

Для сениоров:
- PyTupleObject
- PyVarObject
- tp_alloc, tp_dealloc, freelists
- __len__
- __hash__
- Мутабельность tuple
- PyTuple_Pack, Py_BuildValue
- Виртуальная машина и компилятор: BUILD_TUPLE
- INTRINSIC_LIST_TO_TUPLE
- Оптимизации компилятора
- PySequenceTuple

Обещанный бонус

В видео я обещал, что расскажу в тг, что такое Py_TRASHCAN_BEGIN и Py_TRASHCAN_END.
Документация и исходники: https://github.com/python/cpython/blob/d05140f9f77d7dfc753dd1e5ac3a5962aaa03eff/Include/cpython/object.h#L431-L507

По факту - данные два макроса представляют собой do/while цикл, который позволяет более удобно управлять сборкой "контейнеров" (tuple, в нашем случае). Каждый объект внутри "контейнера" может тоже быть контейнером. Таким образом про Py_DECREF(op->ob_item[i]) можно начать каскадную деаллокацию объектов внутри. И мы можем столкнуться с переполнением стека вызовов.

#define Py_TRASHCAN_BEGIN(op, dealloc) \
do { \
    PyThreadState *tstate = PyThreadState_Get(); \
    if (tstate->c_recursion_remaining <= Py_TRASHCAN_HEADROOM && Py_TYPE(op)->tp_dealloc == (destructor)dealloc) { \
        _PyTrash_thread_deposit_object(tstate, (PyObject *)op); \
        break; \
    } \
    tstate->c_recursion_remaining--;
    /* The body of the deallocator is here. */

#define Py_TRASHCAN_END \
    tstate->c_recursion_remaining++; \
    if (tstate->delete_later && tstate->c_recursion_remaining > (Py_TRASHCAN_HEADROOM*2)) { \
        _PyTrash_thread_destroy_chain(tstate); \
    } \
} while (0);

По сути, мы просто при достижении определенного "большого" значения (50) перестаем выполнять деаллокацию напрямую, просто добавляем объекты в список для деаллокации на потом. Вот и вся хитрость!

Завершение

Если вам нравится мой технический контент – его всегда можно поддержать:
- Материально
- Морально: поделиться с вашими коллегами, чтобы они тоже знали все про кортежи :)

#lkpp

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

В 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 | Чат |

Enum и сложность

Enum – один из самых сложных модулей в питоне, я не шучу. Количество нюансов – просто огромное. Так как я последние несколько дней занимаюсь улучшением поддержки Enum в mypy, то я решил рассказать про интересные штуки из модуля enum, которые вы скорее всего могли пропустить.

Доки: https://docs.python.org/3/library/enum.html Их все равно никто не читает.

global_enum

Чудовищная фича. Просто ужас. Засовывает все значения Enum в sys.modules[module].__dict__:

>>> from enum import Enum, global_enum

>>> @global_enum
... class Pets(Enum):
...     CAT = 1
...     DOG = 2

>>> print(CAT)
CAT

Да, создает новые глобальные константы. Нет, mypy такое пока не поддерживает.
Для чего нужно? Синтаксический сахар для обратной совместимости. Когда были раньше CAT и DOG как константы в модуле, а потом появляется Enum. Но все равно не советую.

_simple_enum

>>> from enum import IntEnum, _simple_enum
>>> 
>>> @_simple_enum(IntEnum)
... class Pets:
...      CAT = 1
...      DOG = 2
... 
>>> print(Pets.CAT)
1

Специальный внутренний хелпер для более быстрого создания Enum классов. Используется в основном внутри CPython для ускорения импорта библиотек. Не поддерживается mypy.

@unique

Декоратор, который позволит найди дубликаты по значениям в ваших Enum типах и вызвать ошибку. Обязателен для использования. Иначе, где-то можно сделать опечатку:

@unique  # <- will find the problem
class Pets(Enum):
      CAT = 1
      DOG = 1  # should be 2

и искать её всю жизнь.

Flag и FlagBoundary

Зачем нужны Flag?

from enum import IntFlag, FlagBoundary

class Permission(IntFlag, boundary=FlagBoundary.STRICT):
     READ = 0
     WRITE  = 1

Для сочетания друг с другом: Permission.WRITE | Permission.READ. Есть 4 разных поведения для таких случаев: https://docs.python.org/3/library/enum.html#enum.FlagBoundary

Советую всегда использовать FlagBoundary.STRICT, если сомневаетесь.

Черная дыра для багов и изменений от версии к версии.

member и nonmember

В Enum есть довольно сложная логика, какие объекты считать за member (часть enum), какие за nonmember (просто какие-то объекты).
Кратко:
- Имя не приватное, имя не __dunder__ и имя не _sunder_
- Имя не в _ignore_
- Не вложенный класс и не метод
- Не инстанс nonmember

Пример:

from enum import Enum, member, nonmember

class Example(Enum):
     _ignore_ = ['a']  # nonmember
     a = 1  # nonmember
     b = 2  # member
     __c__ = 3  # nonmember
     _d_ = 4   # nonmember
     e = nonmember(5)  # nonmember
     __f = 6  # nonmember

     def g(self): ...  # nonmember

     @member
     def  h(self): ...  # member

Думаю, что всем спалось спокойнее без такого знания. Старайтесь делать такие енамы, чтобы не приходилось использовать темную магию. И старайтесь не пользоваться member и nonmember.

Enum в .pyi файлах

Недавно Typing Spec для енамов был изменен. https://typing.readthedocs.io/en/latest/spec/enums.html

Раньше в .pyi файлах мы аннотировали енамы так:

# mymodule.pyi
class Pets(Enum):
     CAT: int
     DOG: int

Однако, теперь такой способ будет создавать два nonmember'а. Правильный способ:

# mymodule.pyi
class Pets(Enum):
     CAT = 1
     DOG = 2

Почему? Потому что значения полей – крайне важно для типа Enum.
Для старого кода mypy выкидывает ошибку.

Обсуждение: а вам нравились Enum в Python? А сейчас?

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

Ковыряем внутрянку nogil

Некоторое время назад я прислал безобидный PR, который исправлял поведение list.insert в nogil сборках CPython. Изменений на 3 строчки. И в ревью случилось два интересных момента.

Во-первых, я случайно удалил оптимизацию.

Было:

PyObject **items;
items = self->ob_item;
items[i+1] = items[i];
items[where] = Py_NewRef(v);

0x0000000000132860 <+96>:    sub    rdx,0x1
0x0000000000132864 <+100>:   sub    rax,0x8
0x0000000000132868 <+104>:   mov    rcx,QWORD PTR [rax]
0x000000000013286b <+107>:   mov    QWORD PTR [rax+0x8],rcx
0x000000000013286f <+111>:   cmp    rsi,rdx
0x0000000000132872 <+114>:   jle    0x132860 <ins1+96>

Стало:

self->ob_item[i+1] = self->ob_item[i];
self->ob_item[where] = Py_NewRef(v);

0x0000000000132858 <+88>:    mov    rdx,QWORD PTR [r12+0x28]
0x000000000013285d <+93>:    lea    rcx,[rax*8+0x0]
0x0000000000132865 <+101>:   mov    rdi,QWORD PTR [rdx+rax*8]
0x0000000000132869 <+105>:   sub    rax,0x1
0x000000000013286d <+109>:   mov    QWORD PTR [rdx+rcx*1+0x8],rdi
0x0000000000132872 <+114>:   cmp    rsi,rax
0x0000000000132875 <+117>:   jle    0x132858 <ins1+88>

В питоне есть аналогичная оптимизация. Использовать

items = self.items
for _ in whatever:
    some_func(items)

более оптимально, чем

for _ in whatever:
    some_func(self.items)

если у вас много объектов в whatever.

LOAD_NAME                3 (self)
LOAD_ATTR                8 (items)  # <- won't happen when `items = self.items`
CALL                     1

Во-вторых, когда мне указали на ошибку, я понял, что я так до конца и не понял разницу между FT_ATOMIC_STORE_PTR_RELAXED и FT_ATOMIC_STORE_PTR_RELEASE.

А вот тут потребуется пояснительная бригада. Смотрите, при использовании nogil, у нас теперь несколько потоков, который выполняют сишный код (который генерирует нужный ASM). И там есть своя специфика. Начнем с того, что есть специальное понятие – Memory Ordering. Базово – как и в каком порядке будут идти обращения от CPU к памяти. Что становится критически важно, когда у нас появляется multi-threading.

Базово, у нас может быть несколько видов memory ordering:
- memory_order_relaxed – Relaxed operation: there are no synchronization or ordering constraints imposed on other reads or writes, only this operation's atomicity is guaranteed
- memory_order_release – A store operation with this memory order performs the release operation: no reads or writes in the current thread can be reordered after this store. All writes in the current thread are visible in other threads that acquire the same atomic variable and writes that carry a dependency into the atomic variable become visible in other threads that consume the same atomic

Полный референс.

__atomic_store_n(&x->ob_item[0], &first, __ATOMIC_RELEASE) будет скомпилировано в

lea     rdx, [rsp+12]
mov     QWORD PTR [rax], rdx

__atomic_store_n(&x->ob_item[0], &first, __ATOMIC_RELAXED) скомпилируется в

mov     rax, QWORD PTR [rbx]
mov     QWORD PTR [rax], rdx

Как можно увидеть: в первом случае происходит непосредственное вычисление адреса rsp+12 инструкцией lea. А во втором случае – мы просто работаем со значением в регистре rbx.

Полный пример на godbolt. Тема для меня новая, продолжаю изучать.

Обсуждение: а вы думали, что nogil – оно просто?

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

--strict-bytes в [email protected]

Вообще, внутри mypy есть много всякой дичи, которую нельзя выразить системой типов нормально. И потому разные хаки просто приколачивают гвоздями. Например, int и float связывают псевдо-"наследованием", чтобы штуки вроде 1 + 1.0 == 2.0 работали нормально.

Раньше так было и с bytes / bytearray / memoryview. То есть буквально можно было писать:

def func(arg: bytes) -> None:
    assert isinstance(arg, bytes)

func(b'')  # ok
func(bytearray(b'123'))  # type checks, fails in runtime
func(memoryview(b'abc')) # type checks, fails in runtime

Даже со всеми --strict флагами. Были спрятанные --disable-bytearray-promotion и --disable-memoryview-promotion, но кто же про них знал?

PEP688

Почему было так? Потому что до PEP688 у нас не было возможности выразить C'шный тип Buffer, который появился недавно. И его выражали сначала как просто bytes (да, bytes был синонимом readonly-buffer долгое время), а потом стали выражать как:

ReadOnlyBuffer: TypeAlias = bytes
WriteableBuffer: TypeAlias = bytearray | memoryview | array.array[Any] | mmap.mmap | ctypes._CData | pickle.PickleBuffer
ReadableBuffer: TypeAlias = ReadOnlyBuffer | WriteableBuffer

Теперь все можно выразить при помощи collections.abc.Buffer.

Следовательно, нам больше не нужны type-promote для bytes / bytearray / memoryview. И флаг --strict-bytes убирает такое приведение из mypy:

# --strict-bytes
def func(arg: bytes) -> None:
    assert isinstance(arg, bytes)

func(b'')  # ok
func(bytearray(b'123'))  # Argument 1 to "func" has incompatible type "bytearray"; expected "bytes"
func(memoryview(b'abc')) # Argument 1 to "func" has incompatible type "memoryview[int]"; expected "bytes"

Советую начинать использовать как можно раньше, потому что такое поведение будет включено в --strict с [email protected], так же как и --local-partial-types. Лучше подготовиться заранее.

Два поста за два дня!

Обсуждение: как вы аннотируете объекты, которые принимают Buffer у себя в коде?

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

Лучший курс по Python 13: print

https://www.youtube.com/watch?v=9aQ-GVlC0nY

В рамках данного видео я рассказываю про:
- Файловые дескрипторы
- Буферизацию вывода
- Устройство TextIOWrapper, BufferedWrite, FileIO
- Зачем нам _pyio?
- Что такое syscall write
- Что происходит после вызова syscall на запись

Для лучшего закрепления материала я предлагаю вам поучаствовать в переписывании print на ASM. Внутри:

static long
sys_write_call(const char *msg, Py_ssize_t size)
{
    // TODO: allow to pass `fd` as `print(file=...)` does.
    long ret;
    asm volatile (
        // TODO: convert this ugly AT&T ASM into beautiful Intel one:
        "mov $1, %%rax\n"             // sys_write call number
        "mov $1, %%rdi\n"             // stdout=1 and stderr=2
        "mov %1, %%rsi\n"             // `msg` address
        "mov %2, %%rdx\n"             // `msg_len`
        "syscall\n"
        "mov %%rax, %0\n"             // save the result
        : "=r"(ret)
        : "r"(msg), "r"(size)         // inputs
        : "rax", "rdi", "rsi", "rdx"  // changed registers
    );

    // TODO: maybe handle special cases like `EINTR`
    return ret;
}

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

Данная задача реально поможет разобраться с print в CPython на самом низком уровне. Мне было очень интересно! Надеюсь, и вам будет.

Ах да, совсем забыл: print в Python2 был ключевым словом, а не функцией. Нам приходилось писать так:

print 'Hello, world!'

Тут print - ключевое слово, а 'Hello, world!' – объект класса bytes.
Еще писали так:

print(1, 2)

Где print - все еще ключевое слово, а (1, 2) - tuple.
И вот так:

from __future__ import print_function

print(1, 2)

Тогда компилятор уже начинал использовать print как функцию. Ужас!

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

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

Что такое GIL в Python?

Кажется, один из золотых вопросов для всех питонистов на собеседованиях.
Обычно, на встречный вопрос "а что конкретно в питоне является GIL?" не может ответить ни один спрашивающий.

Сегодня мы закроем данный пробел в знаниях питонистов.

Global Interpreter Lock не позволяет более чем одному треду работать с Python API за раз. Его можно отключить через --disable-gil в 3.13+, но сегодня мы про такое не будем.

Обратите внимание на ключевую фразу "c Python API". С системными треды могут и должны работать в режиме настоящей параллельности, без GIL. Что и позволяет получить ускорение при использовании threading, когда C код поддерживает такой способ.

Знакомьтесь – вот структура GIL _gil_runtime_state и поведение в ceval_gil.c.

Как можно отпустить GIL?

На уровне C есть макросы: Py_BEGIN_ALLOW_THREADS и Py_END_ALLOW_THREADS, которые отпускают GIL в нужных местах. Пример из модуля mmap:

Py_BEGIN_ALLOW_THREADS
m_obj->data = mmap(NULL, map_size, prot, flags, fd, offset);
Py_END_ALLOW_THREADS

Или time.sleep, который тоже дает работать другим тредам, пока ждет.

Что происходит, когда мы используем данный макрос? Они разворачиваются в:

{
    PyThreadState *_save;
    _save = PyEval_SaveThread();
    // your code here
    PyEval_RestoreThread(_save);
}

PyThreadState является текущим состоянием треда в CPython. Внутри хранится много контекста. Нас особо сильно интересует часть с полями про GIL:

struct PyThreadState {
    struct {
        unsigned int initialized:1;
        /* Has been bound to an OS thread. */
        unsigned int bound:1;
        /* Has been unbound from its OS thread. */
        unsigned int unbound:1;
        /* Has been bound aa current for the GILState API. */
        unsigned int bound_gilstate:1;
        /* Currently in use (maybe holds the GIL). */
        unsigned int active:1;
        /* Currently holds the GIL. */
        unsigned int holds_gil:1;
    } _status;

    // Thread state (_Py_THREAD_ATTACHED, _Py_THREAD_DETACHED, _Py_THREAD_SUSPENDED).
    int state;

    // ...
}

Когда вызывается PyEval_SaveThread и GIL отпускается, то на самом деле мы просто помечаем текущий PyThreadState как:

tstate->_status.active = 0;
tstate->_status.unbound = 1;
tstate->_status.holds_gil = 0;
tstate->state = detached_state;

И вызываем _PyEval_ReleaseLock, который уже правильно изменит _gil_runtime_state.
Как итог – текущий стейт теряет возможность вызывать какие-либо Python АПИ. Даже, например Py_DECREF, и в тредах есть свой refcount, который работает локально, чтобы можно было его вызывать без GIL.

Как треды берут GIL?

Смотрим на thread_run из _threadmodule.c.

_PyThreadState_Bind(tstate);
PyEval_AcquireThread(tstate);
_Py_atomic_add_ssize(&tstate->interp->threads.count, 1);

Там используется PyEval_AcquireThread, который берет GIL в конкретном треде для работы с Python API.
И дальше – отпускаем.

В следующих сериях поговорим про переключение тредов, ParkingLot API, Mutex'ы и прочее.
Обсуждение: сталкивались ли вы на собесах с вопросами про GIL? Стало ли теперь понятнее?

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

Что такое GIL в Python? Вторая часть

Я не закончил! 🌚

Мы не поговорили про очень важную часть: переключение тредов интерпретатором. Треды могут быть очень долгими и не отпускать GIL, мы должны дать поработать каждому.

Простой пример, что так оно и работает:

import threading

def first():
    while True:
        print('first')

def two():
    while True:
        print('two')

a = threading.Thread(target=first).start()
b = threading.Thread(target=two).start()

Выдаст что-то вроде:

first
two
first
first
two
two
two
first
first

Как VM CPython переключает потоки?

Важно: у CPython нет своего scheduler'а для тредов. Он целиком полагается на OS в данном вопросе. Однако, GIL дает возможность переодически останавливать работу с Python API одного потока и дать время какому-то другому. Какому – решает уже OS. Но как?

Во-первых, у нас есть замечательный sys.setswitchinterval и sys.getswitchinterval, которые отвечают за примерное время работы одного потока, которое хранится в _gil_runtime_state:

unsigned long _PyEval_GetSwitchInterval(void)
{
    PyInterpreterState *interp = _PyInterpreterState_GET();
    struct _gil_runtime_state *gil = interp->ceval.gil;
    assert(gil != NULL);
    return gil->interval;
}

Примерный вывод:

>>> import sys
>>> sys.getswitchinterval()
0.005

Далее: значение gil->interval будет использовано для вызова pthread_cond_timedwait. Мы ждем interval для передачи события (чтобы нам дали GIL) через gil->cond. Если уходим в таймаут, значит пришло время забирать GIL на следующем выполнении байткода силой. Смотри про сигналы и PyCOND_T тут.

MUTEX_LOCK(gil->mutex);

unsigned long interval = (gil->interval >= 1 ? gil->interval : 1);
int timed_out = 0;
COND_TIMED_WAIT(gil->cond, gil->mutex, interval, timed_out);

/* If we timed out and no switch occurred in the meantime, it is time
    to ask the GIL-holding thread to drop it. */
if (timed_out && _Py_atomic_load_int_relaxed(&gil->locked)) {
    PyThreadState *holder_tstate =
        (PyThreadState*)_Py_atomic_load_ptr_relaxed(&gil->last_holder);
    assert(_PyThreadState_CheckConsistency(tstate));

    _Py_set_eval_breaker_bit(holder_tstate, _PY_GIL_DROP_REQUEST_BIT);
}

Когда флаг _PY_GIL_DROP_REQUEST_BIT будет установлен, мы сможем в _Py_HandlePending передать GIL кому-то другому:

/* GIL drop request */
if ((breaker & _PY_GIL_DROP_REQUEST_BIT) != 0) {
    /* Give another thread a chance */
    _PyThreadState_Detach(tstate);

    /* Other threads may run now */

    _PyThreadState_Attach(tstate);
}

После вызова _PyThreadState_Detach(tstate) текущий тред потеряет GIL. И снова будет ждать его при вызове _PyThreadState_Attach(tstate). Пока другой работает.

Часть про VM

Теперь вопрос, а кто вызывает _Py_HandlePending и когда?

Вызывается оно из специального "псевдо-опкода" _CHECK_PERIODIC. Раньше там был макрос CHECK_EVAL_BREAKER, и его иногда забывали добавить в нужные места. Оттого события ОС не обрабатывались, GIL не переключался, было весело.

op(_CHECK_PERIODIC, (--)) {
    _Py_CHECK_EMSCRIPTEN_SIGNALS_PERIODICALLY();
    QSBR_QUIESCENT_STATE(tstate);
    if (_Py_atomic_load_uintptr_relaxed(&tstate->eval_breaker) & _PY_EVAL_EVENTS_MASK) {
        int err = _Py_HandlePending(tstate);
        ERROR_IF(err != 0, error);
    }
}

// Вызываем `_CHECK_PERIODIC` в конце каждого `CALL`.
macro(CALL) = 
    _SPECIALIZE_CALL 
    + unused/2 
    + _MAYBE_EXPAND_METHOD 
    + _DO_CALL 
    + _CHECK_PERIODIC;

Вот теперь мы знаем, как переключаются треды внутри CPython.

Одной строкой

- Замечательная (и более длинная) статья Андрея Светлова на русском про GIL, которую не вчера скинули в нашем чате (реклама)
- Предложение по отмене PyGILState АПИ, потому что оно не работает нормально с субинтерпретаторами

Если интересно – закидывайте в коллег!

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

Находки в опенсорсе: [email protected]

Так как чуваки на бусти собрали цель в 50 человек, я сделал видео, которое обещал.

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

Теперь "Находки в опенсорсе" еще и в видео формате!
Рассказываю, что будет в новом релизе: что сломаем, что добавим.

Пока релиз планируется где-то на вторую половину года, а я уже про него рассказываю.

Если понравится формат – поддержи видео, покажи коллеге :)

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